There are many ways to debug your code. You might use an actual graphical debugger, wrestle with GDB, just spam print
statements, or rely on a logging framework to help you generate useful diagnostic output.
Since you're going to need some logging output no matter what, it's always good to heavily instrument your code. Using logging levels, you can control quite well what gets dumped when. Well, "LostLozz" had a co-worker who found an… interesting way to control logging.
if ( LOG.isDebugEnabled() ) {
try {
Integer i = null;
i.doubleValue();
}
catch ( NullPointerException e ) {
LOG.debug(context.getIdentity().getToken() + " stopTime:"
+ instrPoint.getDescription() + " , "
+ instrPoint.getDepth(), e);
}
}
If our logging is configured for debug… force a null pointer exception, then log it. I suspect that they're using the exception to capture the stack trace, and the logging framework will automatically expand that in some useful fashion within the log. That's the best theory I can come up with to explain what's going on here.
Of course, there are built in methods for that, and most logging frameworks probably have some wrapper that gets that information. And I'm just guessing at the intent here, which means they might have just done this because… they could? Because they had some deep belief about the role of logging and believed it should only happen in exception handlers? Because they were hoping to get featured on the site?
It's an exceptional mystery.