|
|
|
| CSS/XHTML Gurus, Web Designers, PHP Devs: You + Zootoo (NJ)? |
| « The Beast | (Unknown) » |
These days, having written about bad code for a few years now, it's pretty rare to uncover a new anti-pattern like the FOR-CASE paradigm, IHBLRIA, or RLB o'PCC. However, having seen snippet after snippet like todays two, I think it's finally time to identify the Null Understanding...
Daniel found this snippet during a code review that was left by a senior developer who, thankfully, is no longer with the company.
void failIfNull(Object o) throws RuntimeException {
if (o == null)
{
throw new RuntimeException(o.getClass().getName() + " is null!");
}
}
This next snippet was submitted anonymously, dug up from a large investment bank's global finance management application...
// An exception may be thrown before the [...] is fully initialised
if (this.equals(null))
{
Warning.showWarning((JFrame) null, title, msg);
}
else
{
Warning.showWarning(this, title, msg);
}
|
Hmm... the bigger issue, besides the shit code, is that the first one was written by a "senior developer". I would imagine a senior developer to know better, but then again this IS the Daily WTF, and most of the snippets/evil stuff here was written by "senior" developers.
|
Re: A Null Understanding
2007-12-14 08:59
•
by
[twisti]
(unregistered)
|
|
One of the best parts of the article got completely ignore by all commenters!
Warning.showWarning((JFrame) null, title, msg); He's casting null into a JFrame! It really makes you wonder what that would do if it would actually work ... create a special null that isn't actually null but an empty JFrame ? |
Re: A Null Understanding
2007-12-14 09:01
•
by
Andy
(unregistered)
|
|
So, strangely enough, I've seen places where that was needed.
In a C++ DLL I was working on there was this weird race condition happening during the unloading of the DLL, and one of the methods would occasionally crash. When walking through it with the debugger I found that the crash happened because `this` was equal to NULL. I never managed to find the root cause of the problem, but just putting `if(this == NULL) { return; } at the top of the function fixed the crash. Since it was happening when the DLL was being unloaded and the results of that function weren't really important anymore we decided it wasn't worth killing ourselves trying to find the root cause anymore. Fortunately, my current project is to rewrite that entire DLL (mainly triggered by Vista incompatibilities. Thanks Vista!), so hopefully I'll be able to avoid that this time. :) |
Re: A Null Understanding
2007-12-14 09:09
•
by
Andy
(unregistered)
|
Actually, I've found doing some quick checks for null at the top of a function and explicitly throwing an exception if they're null is a good thing. While it's true that Java will throw a NullPointerException when dereferencing a null, by doing the check at the beginning of the function and throwing there, you prevent the possibility of getting partway through your processing (and possibly changing some class state) and then causing the exception. Failing fast is almost always better. That said, the check done in that first one is totally broken anyway, as it's dereferencing the null when trying to generate the exception. |
|
Ugh. This is the first time in a while I've actually placed my head into my hands and groaned after looking at code.
|
Re: A Null Understanding
2007-12-14 10:00
•
by
StickyWidget
(unregistered)
|
|
That's not the problem, the problem is the "o.getClass().getName()" snippet. If "o" is Null, then you'll get a NullPointerException thrown, and you'll never get any value for the class name.
Luckily for this joker, a NullPointerException is a subtype of RuntimeException, so everything still works. If he had set it to throw some other kind of exception, he'd be in trouble, as the NullPointerException would crash the whole thing. He'll also never know what class happened to be null. ~Sticky |
| « The Beast | (Unknown) » |