Yesterday, I had a non-descriptive NullPointerException occur within a visual snippet sub-map in WebSphere Integration Developer. The only message written to the log was something that identified which transformation in the sub-map failed. There was nothing about what line was bad. Rather than filling my code full of “Got Here” and “Did this Runs”, I thought I would use the debugging capabilities of the tool.
I thought I would get the ability to move from one snippet to the next to identify the issue. It would have been even sweeter to get hot-code replace, but I don’t mind rerunning my testcase.
What I got was an exercise in bugs, pain and non-intuitiveness. I set my breakpoint at the first point in my visual snippet. The breakpoint popped. I then tried to step into the next line of the snippet and the debugger interpreted that as ‘Run to completion’ so I missed the point of failure.
I realized that I had to just keep manually setting breakpoints for any point where I wanted to stop. My snippet is quite large and finding a NPE is hard. It also took about 6-10 seconds to hit the next breakpoint in the chain. The editors would go crazy resizing and flipping between editors while this was happening.
I decided that the best approach was to use my breakpoints to divide my visual snippet in halfs, identifying which half was failing and then breaking it down even more. Of course, each re-iteration was a completely new invocation which took time.
I also experienced a few times where the breakpoint graphic was created (hello little dot) but it never popped anyway. Another invocation please.
Everything was just so painful and slow to run, that it took about an hour of running tests to figure out that the visual snippet editor didn’t initialize a value.
Next time? I’ll just put in the extraneous system.out’s and forget about even running the debugger again. For all my defenses of the tool and runtime, even I can’t defend how crummy the debugger is.