Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "E4/EAS/Status Handling"
(→e4 (Java)) |
|||
Line 15: | Line 15: | ||
==Eclipse 3.x API== | ==Eclipse 3.x API== | ||
− | StatusManager.getManager().handle( | + | |
+ | |||
+ | <source lang="java"> | ||
+ | public void foo() { | ||
+ | try { | ||
+ | // some operation | ||
+ | } catch (SomeException ex) { | ||
+ | Status failStatus = new Status(IStatus.ERROR, "myPluginId", "Error Message", ex); | ||
+ | StatusManager.getManager().handle(failStatus, StatusManager.SHOW| StatusManager.LOG); | ||
+ | } | ||
+ | } | ||
+ | </source> | ||
+ | |||
Critique: | Critique: | ||
* The API does not separate the client API (notifying about a problem) from the service provider API (acting on a problem). | * The API does not separate the client API (notifying about a problem) from the service provider API (acting on a problem). | ||
** The calling code has to know how the info is presented (BLOCK, SHOW, LOG) | ** The calling code has to know how the info is presented (BLOCK, SHOW, LOG) | ||
− | ** There is no way to hook in and override or augment the error info between the time the client reports it and the time the service provider shows it | + | ** There is no way to hook in and override or augment the error info between the time the client reports it and the time the service provider shows it. |
* The API is currently defined in a UI bundle and as such is not available to lower level bundles. | * The API is currently defined in a UI bundle and as such is not available to lower level bundles. | ||
* We use the Singleton Pattern and thus each client must provide information about itself (like e.g. the plugin id) that could be computed automatically. | * We use the Singleton Pattern and thus each client must provide information about itself (like e.g. the plugin id) that could be computed automatically. | ||
− | * There is no relationship between global error reporting schemes (log, error dialog) and | + | * There is no relationship between global error reporting schemes (log, error dialog) and local error reporting schemes (status dialogs, wizard pages, etc.). If the user opens a wizard that is related to some asynch operation, it should be possible to report the error in a wizard instead of in a dialog. (remember the infamous "error dialog hidden under a wizard because the wrong parent was used") |
* Some asynchronous errors are expected by the calling code and there is no way to specify at that time what actions are suggested or could be taken by the user. | * Some asynchronous errors are expected by the calling code and there is no way to specify at that time what actions are suggested or could be taken by the user. | ||
Line 42: | Line 54: | ||
</source> | </source> | ||
− | The calling code should be dead simple | + | The calling code should be dead simple. The only thing the client should have to care about is what they know (if anything) about the error when it happens. Any complexity in how the error surfaces is handled in the injected services. |
=== Client code === | === Client code === |
Revision as of 15:36, 29 October 2009
(Status: in progress)
Something unexpected happened in a component, for example:
- an operation requested by the user could not be performed at all
- an operation could only be performed partially
- an exception happened, but there is no immediate consequence for the user
Typically, in these situation, some or all of the following are known:
- how severe the situation is
- if the user needs to be informed
- if the user can do anything about it
- a string describing the unexpected situation
- an exception
- an application-specific object that should be made available to application-level error handling code
Eclipse 3.x API
public void foo() { try { // some operation } catch (SomeException ex) { Status failStatus = new Status(IStatus.ERROR, "myPluginId", "Error Message", ex); StatusManager.getManager().handle(failStatus, StatusManager.SHOW| StatusManager.LOG); } }
Critique:
- The API does not separate the client API (notifying about a problem) from the service provider API (acting on a problem).
- The calling code has to know how the info is presented (BLOCK, SHOW, LOG)
- There is no way to hook in and override or augment the error info between the time the client reports it and the time the service provider shows it.
- The API is currently defined in a UI bundle and as such is not available to lower level bundles.
- We use the Singleton Pattern and thus each client must provide information about itself (like e.g. the plugin id) that could be computed automatically.
- There is no relationship between global error reporting schemes (log, error dialog) and local error reporting schemes (status dialogs, wizard pages, etc.). If the user opens a wizard that is related to some asynch operation, it should be possible to report the error in a wizard instead of in a dialog. (remember the infamous "error dialog hidden under a wizard because the wrong parent was used")
- Some asynchronous errors are expected by the calling code and there is no way to specify at that time what actions are suggested or could be taken by the user.
e4 (Java)
Clients should be able to write something like:
@Inject Provider<StatusHandler> statusHandler; @Inject Provider<StatusReportingService> statusReportingService; public void foo() { try { // some operation } catch (SomeException ex) { statusHandler.get().handle(ex, IStatus.ERROR, "some message", statusReportingService.get()); } }
The calling code should be dead simple. The only thing the client should have to care about is what they know (if anything) about the error when it happens. Any complexity in how the error surfaces is handled in the injected services.
Client code
- The calling code expects some errors and has predefined user messages to describe it
- Unexpected exceptions percolate to a global handler as today
StatusHandler
- StatusHandler consults with registered interpreters
- Status may surface as originally reported or get augmented or reinterpreted depending on configuration.
- Status finally gets surfaced via the reporting service
StatusReportingService
- The StatusReportingService decides how the error is shown (in a wizard, in an error dialog, etc.)
- A smart status reporting service may be able to offer assistance to the user (quick fixes, take the user back to where they launched the asynch op that failed, help)
- Do we want the ability to chain these? (report to the user and log to the help desk)