Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

E4/EAS/Status Handling

< E4‎ | EAS
Revision as of 16:11, 29 October 2009 by Susan franklin.us.ibm.com (Talk | contribs) (e4 (Java))

(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 triggers some background work, they expect the status to be reported in the wizard rather than be interrupted by a dialog.
  • Some asynchronous errors are expected by the calling code and there is no easy way to specify what actions are suggested or could be taken by the user when the error is reported (Bug 273137).

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) {
     // I thought this might happen, I think it's an error
     statusHandler.get().handle(ex, IStatus.ERROR, "Error Message", statusReportingService.get());
  } catch (AnotherException ex) {
     // I know nothing about the details, probably an error?
     statusHandler.get().handle(ex, statusReportingService.get());
  }
}
  • The calling code should be dead simple. The only thing the client should have to specify is what they know (if anything) about the error.
  • Complexity in how the error surfaces is implemented in the injected services.
  • Ensure that status handlers and reporting services can evolve incrementally as e4 matures without impacting the original client code
  • Ensure that the status objects can evolve so that client could choose to improve/annotate their description of the original error as smarter services are provided. (Status properties?)

Client code

  • The calling code expects some exceptions and has predefined user messages to describe what went wrong
  • Other exceptions must be caught but are not fully understood by the client, just let some default reporting happen
  • Unexpected (runtime) exceptions percolate to a global handler as today
  • Client can add properties later to the status to take advantage of evolving reporting schemes

StatusHandler

  • StatusHandler consults with registered interpreter(s)
    • Chains (ordered lists of status interpreters)
    • Overrides
      • Service rankings determine a single winner
      • How to handle a tie?
  • Status may surface as originally reported or get augmented or reinterpreted depending on configuration.
    • Gather additional information about an error when it occurs (for reporting purposes)
    • One product's error is another product's "so what?" (See Bug 174515).
    • Alternate interpretation of an error
      • Eclipse SDK: "Error: Connection timed out on http://example.com"
      • My RCP Product: "Info: The XYZ company server is down for maintenance between 6pm and 8pm. Please try again later."

StatusReportingService

  • The StatusReportingService decides how the error is shown (in a wizard, in an error dialog, log, send to help desk, 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)
  • How are multiple reporting services handled, is only a single one injected?
    • Chains (ordered lists of reporters)
    • Wrapped (a la ProgressMonitorWrapper)
    • Service rankings determine a single winner
      • How to handle a tie?

Back to the top