Breaking when a method returns null in the Eclipse debugger

Question

I'm working on an expression evaluator. There is an evaluate() function which is called many times depending on the complexity of the expression processed.

I need to break and investigate when this method returns null. There are many paths and return statements.

It is possible to break on exit method event but I can't find how to put a condition about the value returned.

Answer 1

I got stuck in that frustration too. One can inspect (and write conditions) on named variables, but not on something unnamed like a return value. Here are some ideas (for whoever might be interested):

1. One could include something like evaluate() == null in the breakpoint's condition. Tests performed (Eclipse 4.4) show that in such a case, the function will be performed again for the breakpoint purposes, but this time with the breakpoint disabled. So you will avoid a stack overflow situation, at least. Whether this would be useful, depends on the nature of the function under consideration - will it return the same value at breakpoint time as at run time? (Some s[a|i]mple code to test:)

class TestBreakpoint {
    int counter = 0;
    boolean eval() { /* <== breakpoint here, [x]on exit, [x]condition: eval()==false */
        System.out.println("Iteration " + ++counter);
        return true;
    }
    public static void main(String[] args) {
        TestBreakpoint app = new TestBreakpoint();
        System.out.println("STARTED");
        app.eval();
        System.out.println("STOPPED");
    }
}
// RESULTS:
// Normal run: shows 1 iteration of eval()
// Debug run: shows 2 iterations of eval(), no stack overflow, no stop on breakpoint

2. Another way to make it easier (to potentially do debugging in future) would be to have coding conventions (or personal coding style) that require one to declare a local variable that is set inside the function, and returned only once at the end. E.g.:

public MyType evaluate() {
    MyType result = null;
    if (conditionA) result = new MyType('A');
    else if (conditionB) result = new MyType ('B');
    return result;
}

Then you can at least do an exit breakpoint with a condition like result == null. However, I agree that this is unnecessarily verbose for simple functions, is a bit contrary to flow that the language allows, and can only be enforced manually. (Personally, I do use this convention sometimes for more complex functions (the name result 'reserved' just for this use), where it may make things clearer, but not for simple functions. But it's difficult to draw the line; just this morning had to step through a simple function to see which of 3 possible cases was the one fired. For today's complex systems, one wants to avoid stepping.)

3. Barring the above, you would need to modify your code on a case by case basis as in the previous point for the single function to assign your return value to some variable, which you can test. If some work policy disallows you to make such non-functional changes, one is quite stuck... It is of course also possible that such a rewrite could result in a bug inadvertently being resolved, if the original code was a bit convoluted, so beware of reverting to the original after debugging, only to find that the bug is now back.