Stop on specific NullPointerException in Eclipse

20. December, 2017

TL;DR: Find the line where the exception occurs and then add a conditional breakpoint which checks the local variables for values that would trigger the exception.

In Eclipse, you can stop on any exception by using the menu Run -> “Add Java Exception Breakpoint…“.

That’s great but it doesn’t help when you want to stop on a certain exception on a certain line. It’s a big problem with code that uses exceptions for control flow – you could have thousands of those exceptions before you get to the one which you care about.

In my case, I had a NullPointerException in java.util.concurrent.ConcurrentHashMap:

    public V get(Object key) {
        Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
        int h = spread(key.hashCode()); <-------- key is null
        ...

I tried to add a conditional breakpoint here with the condition key == null but Eclipse complained that it couldn’t compile the expression (probably missing debug information).

The method was called from Jetty’s ClassInheritanceHandler, so I added a conditional breakpoint there.

That’s another reason to copy method results into local variables before using them.

Leave a Comment » | Software | Tagged: , , | Permalink
Posted by digulla

Paul Bilnoski: On Exception Management

3. January, 2011

If you want to widen your understanding of exceptions and how to handle them, you should read Paul Bilnoski’s post “On Exception Management”

1 Comment | Software | Tagged: , | Permalink
Posted by digulla

Java tip: Getting most out of exceptions

28. December, 2010

Exceptions should have two purposes: 1. Clean up after an error and 2. help you solve the issue. Sadly, many Java developers often forget about #2.

So you end up with an exception thrown in SignatureFileVerifier (no source). Or even in a native method. The error message is:

Invalid signature file digest for Manifest main attributes

Right. Which tells us exactly … nothing. The stack trace isn’t better:

java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
	at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:221)
	at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:176)
	at java.util.jar.JarVerifier.processEntry(JarVerifier.java:233)
	at java.util.jar.JarVerifier.update(JarVerifier.java:188)
	at java.util.jar.JarFile.initializeVerifier(JarFile.java:325)
	at java.util.jar.JarFile.getInputStream(JarFile.java:390)
	at sun.misc.URLClassPath$JarLoader$1.getInputStream(URLClassPath.java:620)
	at sun.misc.Resource.cachedInputStream(Resource.java:59)
	at sun.misc.Resource.getByteBuffer(Resource.java:84)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:249)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
	at org.eclipse.jface.action.LegacyActionTools.initLocalizedModifiers(LegacyActionTools.java:699)
	at org.eclipse.jface.action.LegacyActionTools.findLocalizedModifier(LegacyActionTools.java:356)
	at org.eclipse.jface.action.LegacyActionTools.convertLocalizedAccelerator(LegacyActionTools.java:167)
	at org.eclipse.jface.action.Action.setText(Action.java:665)
	at de.pdark.epen.editor.actions.ForwardAction.(ForwardAction.java:29)
	at de.pdark.epen.editor.actions.ForwardActionTest.testCreate(ForwardActionTest.java:21)

So LegacyActionTools needs a class. Which one? Since I don’t have the source, how can I set a breakpoint?

Simple: Set the breakpoint in the constructor of the exception! Even native code has to pass through here, eventually.

Leave a Comment » | Software | Tagged: , , , | Permalink
Posted by digulla

A Different View on Exceptions

30. January, 2009

The discussion about checked/unchecked exceptions is almost as old as Java. While we all have a point in your stance towards this, maybe we are looking at the problem from the wrong angle. Manuel Woelker wrote an article which concentrates on the receiver of the exception, the user, and how exceptions should behave to help the user: Exceptions From a User’s Perspective.

In a nutshell:

[…]the error message displayed to the user should also explain what can be done to correct the situation

Take this code:

Foo foo = cache.get( key );
Preconditions.checkNotNull( foo, "foo is null" );

This error message is wasting someone’s time. Use this instead:

Foo foo = cache.get( key );
Preconditions.checkNotNull( foo, "No Foo for %s", key );

See? That actually tells you why foo is null.

Can we do better than that? Yes, we can:

Foo foo = cache.get( key );
Preconditions.checkNotNull( foo,
    "No Foo for %s. Valid keys: %s",
    key, cache.keySet() );

As you can see, by adding just a little bit of extra information, you can prevent someone (maybe even yourself) from starting the debugger, trying to reproduce the bug and then trying to pry some useful hints of the cause from the runtime.

Leave a Comment » | Software | Tagged: , , | Permalink
Posted by digulla