Time for action – catching exceptions

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 SampleHandler class, by adding the following just before the MessageDialog.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 NullPointerException in 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:

What just happened?

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).

Tech Concepts

Programming languages

Tech Tools

Unlimited access to the largest independent learning library in tech of over 8,000 expert-authored tech books and videos.

Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.

50+ new titles added per month and exclusive early access to books as they are being written.

Eclipse Plug-in Development Beginner's Guide - Second Edition

By : Alex Blewitt

Eclipse Plug-in Development Beginner's Guide

By: Alex Blewitt

Overview of this book

Time for action – catching exceptions

What just happened?

Eclipse Plug-in Development Beginner's Guide - Second Edition

By : Alex Blewitt

Eclipse Plug-in Development Beginner's Guide

By: Alex Blewitt

Overview of this book

Time for action – catching exceptions

What just happened?

Confirmation

Buy this book with your credits?

Submit Your Feedback

Create a Free Account To Continue Reading

Sign in to activate your 7-day free access