Platform UI Error Handling

Error manager & Error handlers

Error manager

Error manager decides what to do with a problem occurred in an application.

Error manager (EM) is a part of the framework which can be used directly or by calling method handleError() from plugin (in a similar way as log() method) which delegates problems to the error manager.

Method handleError() takes Status as an attribute (or ErrorStatus which carries additional info about problem)

Error manager decides which error handler should handle the problem.

Error handlers

Error handler (EH) is related to a plugin. It can be defined as an extension point. If plugin is defined as a product, its error handler is a product error handler (ProductEH).

If we want to introduce company (admin) error handler (CompanyEH) we have to install something what we can call Support Centre plugin and its EH becomes company error handler.

Error handler decides how serious a problem is for plugin, product or company. It is not responsibility of a plugin to decide how serious a problem is.

Error handler can log error to a file, can do nothing with it or show error dialog (see Error Dialog).

Questions

How can error handlers recognize severity of the problem? Is it necessary?

What extra information should be carried in Status to help error handler to recognize type, severity of problems.

Policy of choosing error handlers by the manager The policy can be fixed (as Christophe suggested) or can be defined dynamically in for instance xml file assigned to the application.

Fixed policy can look like this

If company handler is defined errors are forwarded to it. If no company handler, errors are delegated to product handler. If no product handler, manager checks if plugin has its own handler. If not, manager asks all plugin handlers whether they want to handle the error. (Small change to Christophe way) At the end we have eclipse handler which handles problems in “let’s say eclipse way” ;-)

Each EH can have at least two methods handleError() – which actually handles a problem canHandleError() – which asks a handler if it can handle a problem

Questions! • Fixed or dynamically defined policy? If dynamically defined… what can be dynamic?  • If fixed, which policy is better? • Should we delegate problems to a “lower layer” (from company to product EH, from product do plugin EH) if EH can’t handle them?

Error dialog

This is the way of showing problems to application users.

Main requirements - shows list of the problems already occurred in the application - shows details of the problems - shows view which helps user to handle or report the problems

Each problem on the list should have error reporting view (ERView) associated to it. This relation can be set in error handler which handles the problem. This reporting view will be showed in the tray part of the dialog.

For Eclipse EH it can be simply a basic view with stack trace. For company or product EH it can be a html view with a form for registering the problem or for checking the state of the problem.

Below sample error dialogs with and without extra details area.

In a tray of the dialogs there is an error reporting view. In these cases this is a html view with form to raise a problem in the eclipse bugzilla.

Questions! • How long the problem should be visible on the list (until it is handled? or user can decide that it should be deleted) • Should the problem list be persisted? • Is it necessary to have both details and tray view? We can use tray to show details of the problem. • Should we show each problem or error, or should we group the same problems and show them as one line in the list?

Although we will be able to show (use) the error dialog directly, it would be a good practice to do this through error manager.

Error types (related to problem list)

Developer can define error types for a plugin as extension points.

Each such a type can define icon of the error type and other things which can be rendered in the error dialog list. Of course if we want to use error types in other areas, it can have more parameters and attributes.

The error type has id. We can use error class name (for instance NullPointerException) as the id.

If we have Status with NullPonterException in the error dialog list, the error type with this id and for plugin which caused the error will be used to render the problem in the list.

If we define error type only for super type (e.g. error, exception or runtime exception) it will be used for errors which inherit from this type.

The same as in EH’s we can override error types in plugin defined as a product or in Support Center plugin.