Although it's easy to put a breakpoint in the catch block, this is merely the location where the failure was ultimately caught, not where it was caused. The place where it was caught can often be in a completely different plug-in from where it was raised, and depending on the amount of information encoded within the exception (particularly if it has been transliterated into a different exception type) may hide the original source of the problem. Fortunately, Eclipse can handle such cases with a Java Exception Breakpoint.
- Introduce a bug into the execute method of the
SampleHandlerclass, by adding the following just before theMessageDialog.openInformation()call:window = null; - Click on the hello world icon.
- Nothing will appear to happen in the target Eclipse, but in the Console view of the host Eclipse instance, the error message should be seen:
Caused by: java.lang.NullPointerException at com.packtpub.e4.hello.ui.handlers.SampleHandler.execute at org.eclipse.ui.internal.handlers.HandlerProxy.execute at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute
- Create a Java Exception Breakpoint in the Breakpoints view of the Debug perspective. The Add Java Exception Breakpoint dialog will be shown:
- Enter
NullPointerExceptionin the search dialog, and click on OK. - Click on the hello world icon, and the debugger will stop at the line where the exception is thrown, instead of where it is caught:
The Java Exception Breakpoint stops when an exception is thrown, not when it is caught. The dialog asks for a single exception class to catch, and by default, the wizard has been pre-filled with any class whose name includes *Exception*. However, any name (or filter) can be typed into the search box, including abbreviations such as FNFE for FileNotFoundException. Wildcard patterns can also be used, which allows searching for Nu*Ex or *Unknown*.
By default, the exception breakpoint corresponds to instances of that specific class. This is useful (and quick) for exceptions such as NullPointerException, but not so useful for ones with an extensive class hierarchy, such as IOException. In this case, there is a checkbox visible on the breakpoint properties and at the bottom of the breakpoints view, which allows the capture of all Subclasses of this exception, not just of the specific class.
There are also two other checkboxes that say whether the debugger should stop when the exception is Caught or Uncaught. Both of these are selected by default; if both are deselected, then the breakpoint effectively becomes disabled. Caught means that the exception is thrown in a corresponding try/catch block, and Uncaught means that the exception is thrown without a try/catch block (this bubbles up to the method's caller).