So far, the code has been using an information dialog as the demonstration of the handler. There's an equivalent method that can be used to create an Error message instead. Instead of calling MessageDialog.openInformation(), there's an openError() that presents the same kind of dialog, but with an error message.
Using dialogs to report errors may be useful for certain environments, but unless the user has just invoked something (and the UI is blocked whilst doing it), reporting errors via a dialog is not a very useful thing to do. Instead, Eclipse offers a standard way to encapsulate both success and failure, in the Status object and the interface IStatus that it implements. When a Job completes, it returns an IStatus object to denote success or failure of executing the Job.
- Introduce an error into the
HelloHandlermethodrunthat will generate aNullPointerException. Add acatchto the existingtryblock and use that to return an error status. Since theOK_STATUSis a singleton instance ofStatus, it is necessary to instantiate a newStatusobject with the error information enclosed:protected IStatus run(IProgressMonitor monitor) { try { SubMonitor subMonitor = SubMonitor.convert(monitor,"Preparing", 5000); subMonitor = null; // the bug ... } catch (RuntimeException e) { return new Status(IStatus.ERROR, Activator.PLUGIN_ID, "Programming bug?", e); } finally { - Run the Eclipse instance, and invoke the
Hellocommand. An exception will be generated, and the status object containing the information needed will be passed to Eclipse. If the job is running in the foreground, the job scheduler will present the status message if it is an error:
- Open the Window | Show View | Other | General | Error Log in the target Eclipse instance to see the error, which has also been written into the
workspace/.metadata/.logfile:
- Double-click on the entry in the error log to bring up specific details:
- Instead of returning an error status, it's also possible to log the error message programmatically, using
StatusReporter. This requires that the packageorg.eclipse.e4.core.servicesbe imported in theManifest. TheStatusReporteris a service that can be injected. To just log the information but keep going, don't return thestatusobject:public void execute(final UISynchronize display, final ICommandService commandService, final StatusReporter statusReporter) { ... } catch (NullPointerException e) { // return new Status(IStatus.ERROR, // Activator.PLUGIN_ID, "Programming bug?", e); Status status = new Status(IStatus.ERROR, Activator.PLUGIN_ID, "Programming bug?", e); statusReporter.report(status, StatusReporter.LOG); } ... - Run the target Eclipse instance, invoke the
Hellocommand, and see the error being logged without displaying a dialog. - Modify the status flags to add
SHOWas well:statusReporter.handle(status, StatusReporter.LOG | StatusReporter.SHOW );
- Re-run the Eclipse instance, invoke the
Hellocommand, and the error will be shown as well as logged. - Finally, remove the bug from the
HelloHandlerso that it doesn't cause errors:// subMonitor = null; // the bug
First, openError was used to show an error, which is useful for specific cases, such as when the user is interacting with the UI and has just done an operation that is problematic.
The next step looked at status reporting and handling in Eclipse, including how exceptions are captured and associated with a specific plugin. A Status was used to indicate a single issue—though there's a MultiStatus that can be used to add more Status instances if required. Generally, the status should be logged but not shown as dialogs popping up in the user's screen (especially from a background job) are a UX anti-pattern.
These flags can be combined; so LOG indicates that the status message should be logged but not otherwise displayed to the user, while SHOW indicates that the message should be shown in the standard dialog. Both of these happen asynchronously; the code will continue executing after invoking these calls, regardless of how the messages are shown to the user. There is a BLOCK flag as well, which prevents continued execution of the thread, but this should not be used as it may lead to inadvertent deadlocks.