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

Difference between revisions of "E4/EAS/Status Handling"

< E4‎ | EAS
(e4 (Java))
(Current Eclipse 3.x API)
Line 14: Line 14:
 
* an application-specific object that should be made available to application-level error handling code
 
* an application-specific object that should be made available to application-level error handling code
  
==Current Eclipse 3.x API==
+
==Eclipse 3.x API==
 
StatusManager.getManager().handle(status, style) where style is a hint (one of BLOCK, SHOW, LOG), the status object contains the descriptive string, the severity (INFO, WARNING, ERROR), and an optional exception
 
StatusManager.getManager().handle(status, style) where style is a hint (one of BLOCK, SHOW, LOG), the status object contains the descriptive string, the severity (INFO, WARNING, ERROR), and an optional exception
  

Revision as of 15:30, 23 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

StatusManager.getManager().handle(status, style) where style is a hint (one of BLOCK, SHOW, LOG), the status object contains the descriptive string, the severity (INFO, WARNING, ERROR), and an optional exception

Critique:

  • The API does not separate the client API (notifying about a problem) from the service provider API (acting on a problem).
  • 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.

e4 (Java)

Clients should be able to write something like:

@Inject Provider<StatusHandler> statusHandler;
 
public void foo() {
  try {
    // some operation
  } catch (SomeException ex) {
    statusHandler.get().handle(ex, "some message", StatusHandler.SHOW);
  }
}

Back to the top