- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
At least the function in the first snippet's execution is faithful to its name...
Admin
The C++ Standard says that dereferencing a null pointer is undefined behaviour. It does not result in a call with 'this == NULL'. It is not a seg fault. It does not 'work if it's not a virtual function'. It is not a corner of the language. It does not throw an exception. It is UNDEFINED.
So could everyone please stop trying to define its behaviour. You're wrong. Your compiler may result in something which makes some kind of practical sense to you, but that's not the same as defining 'what it does', because there is no definition for what it does.
Admin
Actually, it tells the compiler which variant of an overridden method to use.
Warning isn't a static J2SE class, so I'm going to assume that it's a JDialog subclass. JDialog has constructors that can take either a Dialog or a Frame as the parent window, and the caller is allowed to pass null for this parameter.
However, if you pass null, the compiler has no way to determine which variant to use, because it relies on static typing for variant selection (all strongly-typed languages behave the same way). So the cast gives the compiler the information needed to disambiguate.
An alternative would be:
Admin
It would actually work and is ignored on purpose by anyone who knows how compilers work.
This would be actually NEEDED if there were more than one implementations of Warnig.showWarning, i.e:
Warning.showWarning(JFrame f, String title, String msg); and Warning.showWarning(JDialog f, String title, String msg);
Then, if you tried to simply call:
Warning.showWarning(null, "", "");
you'd get a compiler error along the line of "reference to showWarning is ambiguous , both methods apply".
Admin
You know, given that absolutely no one else has mentioned it yet in this thread, I thought I'd chime in here and say that this sort of cast would be necessary if there were multiple overloaded versions of showWarning that differed only in the type of the first parameter.
Admin
Actually, failIfNull() uselessly turns a NullPointerException into a RuntimeException. This must be a too-clever way to let worker threads report NullPointerException.
As I recall, a Java thread can only catch its child (worker) threads RuntimeExceptions. So, it would make sense to change a "checked exception" into a RuntimeException, but NullPointerException is already a RuntimeException subclass.
See: http://www.ibm.com/developerworks/java/library/j-jtp0924.html near "RuntimeException is the leading cause of thread death".
Admin
That's not a WTF. It's possible that the showWarning method is overloaded, e.g. with these signatures:
public void showWarning(JFrame frame, String title, String msg);
public void showWarning(JApplet frame, String title, String msg);
If you were to make a call to:
Warning.showWarning(null, title, msg);
the compiler would not know which showWarning you were trying to call, hence the need for a cast.
Admin
Actually, it does exactly what it's supposed to do. It throws a RuntimeException if o is null. Granted, it does so a great deal sooner than the explicit "throw" statement is reached, and doesn't contain any of the error message. And as has been said, the method signature includes a throws clause which is in this case pointless.
But other than that, this code is perfectly safe. It could be rewritten simply as this:
public void failIfNull(Object o) { o.toString(); }Admin
No, it doesn't. It throws a NullPointerException long before the RuntimeException is created and thrown.
Admin
I confess to having committed the same mistake as in failIfNull()... of course, that code never went beyond my development environment. It didn't take long to realize that was stupid. By the way, a minor additional WTF is that they (try to) throw RuntimeException instead of a more specific IllegalArgumentException.
Admin
That isNull code is a bit like checking if the car has run out of gasoline with a lighter in the gascap.
Admin
Actually, it's not that surprising. In C++, if you have a non-virtual function, then nothing actually dereferences the implicit "this" object unless the code in your function does it. As a result, you don't get a crash until you try to actually access members inside the function. Putting the check for this == NULL at the top prevents this crash since you avoid dereferencing this if it's null.
More to the situation at hand, it's not surprising that you'd have issues like that in DLL unloading, as that's when objects tend to become deleted, so you have an object deleted but are trying to do some cleanup on it anyway.
Admin
Granted the JFrame cast is pointless here, there are times that you should specifically cast a null to a type:
public class VarargsNull { public static void test(String... o) { } public static void main(String... args) { /* The next line gives compile-time warning: * The argument of type null should explicitly be cast to String[] for * the invocation of the varargs method test(String...) from type * VarargsNull. It could alternatively be cast to String for a varargs * invocation */ test(null); test((String[])null); // This is ok. test((String)null); // This is ok. } }Admin
Firstly:
Warning.showWarning((JFrame) null, title, msg);
The null will be cast as a JFrame, but will still nonetheless be null. No difference really, in that an exception will still be thrown if you attempt to use the specified object.
The main point though, and I must stress that this point is common to all software development and overridingly important, is that projects tend to get overcomplicated as a result of the desire to abstract functionality.
As a software engineer with 15 years experience, the single most valuable insight I have to pass on to others, is: HARD CODE where it makes sense to do so. Yes, this goes against the grain a lot. However, it avoids many many problems. Take 'Enterprise' systems for example -- they are 98% glue, abstraction, obfuscation, and confusion. Is it better to call a factory method to instantiate a concrete subclass, or to call the subclass's constructor directly? (you save a lot of coding; and there's no chance of forgetting to update the factory after building your new class) Is it better to move all your SQL code to sprocs, resource files, or other obscure repositories -- or to hard code the query strings? (I can't think of very many reasons to use stored procs from app code...)
The lesson here is that what most of us are supposed to be writing is business logic, not plumbing and associated crap. Enterprise frameworks which do this kind of ridiculous overkill are all well and good for astonishingly large systems; but everyone seems to a) overestimate the final size of the system (and thus overengineer it), and b) prefer writing wishy-washy boilerplate code instead of solving the actual problem at hand. Like premature optimization, over-enterprization is a programming sin of the most heinous order.
Code should always reflect a balance between the need for reuse of functionality (genericity), and concrete, application-specific logic -- preferably implemented with the minimum of fuss and the maximum of clarity.
Laziness is a virtue, and it's one that's practised religiously by the most effective software people at all times. Do your best to take the easy route wherever it makes sense to do so ( ... which is most of the time!)
Admin
No he's not. If this is null, null pointer exception. And this is in a class, so it's testing itself for null. It cannot be null if it's running ;-)
Admin
I'd stick a breakpoint on the return statement, and when the breakpoint triggers, see what the backtrace looks like. If "this" is null, it usually means there's a howler of a WTF somewhere else in the program.
Admin
When talking about NULLs - I found interesting fact, that in Pascal diagrams is possibility to construct syntactically valid command with dereferenced NULL (well nil in Pascal). Such as some_proc(some_type(nil^)); And better of all it even can be valid! The some_proc must have parameter of the some_type type, called by referrence. procedure some_proc(var X:some_type) Then the variable X contains not the value of the parameter given, but is pointed to the same location, where the parameter is stored. Which is nil (not defined place). And the procedure can then test the address of its local variable X and do something interesting after discovering, that the address of the X is nil (nowhere). In that case it cannot use the value of X ofcourse, but can use it as a marker, that the parameter was not filled.
(Yes technically it is the same, as using some_func(null) if C++, with definition int some_func(char * X) but with much more funny/obfuscated style)
Admin
"this" is null each time you call a method on a NULL object pointer in most C++ implementations. If it's a virtual function, it'll crash before getting to the method (as there's no vtable), but if it's non-virtual, or called in non-virtual scope (constructor, explicitly qualified, etc) then you can totally call a member function on a NULL pointer. It only crashes if you try to then access some non-static member field or virtual function.
The test for "this" as "null" was mostly WTF-ey because the code would do the same even if you didn't test for NULL.
Admin
You mean, apart from performance? I've worked with databases that would auto-optimize schema and index physical layout for specific stored procedures. Also, anything that's not just a single query is likely to run better when there's not a round-trip for each cycle of an iteration (if you dare use those CURSORs...)
Admin
Perhaps they wanted to throw an exception - any exception if something was null and that function conveniently did the job.
Admin
Null has a type !
When i was set to upgrade a ASP.NET/VB# project earlier this year, we had problems with Null not being cought by function overloads...
the class had multiple helper functions like this
//C# example public string helper(string s){ if(s==null) return ""; else return s; }
however, some functions had to take care of Null, of 2 different types, DBNull and just Null.
so it makes sense to actually pull out its type, and write that in an exception, if you want to know which type went Null...
Captcha damnum
Admin
It would segfault if the compilter dereferences p, but it doesn't. The compiler knows what class p is (its a myObject) so it compiles a jmp to the Print function in the vtable of myObject, passing in the value of p as the first argument. As long as the function doesn't make use of the "this" pointer everything will work just fine.
Admin
Nope. I had to google for it.
I'm in one of these 12-steps groups. We have to post in a forum each one of our small achievements to gain self-confidence ;)
Admin
Sometimes you need to do things like this if you've got two "Warning.showWarning(x, y, z)" methods that differ by their types. Like Warning.showWarning(JDialog, title, msg) and Warning.showWarning(JFrame, title, msg). If you pass null the compiler will complain about an ambiguous invocation. You actually need to cast the null. Weird, but there you go.
Admin
He's casting null into a JFrame!
Actually that must sometimes be used to disambiguate between polymorphic functions. Otherwise the compiler would complain that it doesn't know what exact function to invoke there.
Admin
If you had two methods void foo(String bar); void foo(Integer bar);
and you wanted to call the first one with null parameter, then you would have to cast null, otherwise the compiler wouldn't know which method to call...
Admin
Casting null to a special type is sometimes necessary if the method call would otherwise be ambigous.
For example, take the following two method signatures:
void foo(a:Alpha) void foo(b:Beta)
It's impossible to compile a call like foo(null). You have to cast null to one of the possible types.
Admin
Why does this work then:
class Blaat { private int x;
] }
Admin
Actually, the exception would get thrown at the this.equals(null) check, making it fail even more.
Admin
If you have two methods with different signatures, let's say foo(String x) and foo(Integer x) and you call foo(null), you will actually get an error at compile time (Ambiguous method invocation or something like this).
Using foo((Integer)null) makes sure that the compiler selects the foo(Integer x) method. Nothing special here, just a hint to the compile, which method to use.
Admin
this.equals(null) is not the same as this == null. this.equals is a method call that fails (null pointer exception) when this is null and then "if (this.equals(null))" cannot be true, so either you get a null pointer exception or you are in the else case. This is the same problem that StickyWidget showed.
Admin
The cast may be required. There may be overloaded versions of showWarning method (eg. showWarning(JFrame, String, String) and showWarning(JWindow, String, String)). The case indicates which version of the method is called.
Admin
This is actually an example of the more general case for making reasonableness checks in incoming data. If such checks can be made inexpensively they are a good idea.
Admin
class CWhatever;
int main() { CWhatever* pNew = NULL; pNew->DoSomething(); }
class CWhatever { public: void DoSomething() { // this == NULL } };
Dereferencing a NULL pointer to call a class method on it will give you what you described. That right there was probably your problem.
Admin
Also, props to me for not reading the thread :)
Admin
I agree.
public void foo(String s) { if(s == null) throw new NullPointerException("Argument s can't be null!");
PreparedStatement ps = .... ps.setString(1, s); ps.executeUpdate();
....
if(s.length() > 5) { .... } PreapredStatement ps2 = ... ... ps2.executeUpdate(); }
Putting the first if statement there is good form, because otherwise, the first PreparedStatement will execute, but the second PreparedStatment will not execute. Woops! Now the system is in an inconsistent state.
But of course, the correct exception to throw for an illegal null, is a null pointer exception.
Dental and prosthodontics in Beverly Hills
Admin
Seventeen times. Seventeen separate times, people write about the need for passing (smth)null to facilitate overload-resolution. That's seventeen out of 86 posts, as I write this.
Somewhere along the way, we get this little pearl of wisdom:
No s***, sherlock - read much? Exactly who is using 'the specified object' now?If there's a lesson to be learned here, we can't say that it's in favor of well-documented code - seems too many people are averse to reading comments of any kind.
Admin
dude, the cast is required to tell the compiler which 'showWarning' method should be used. There are several, one takes a jframe and one takes a jwindow if i remember correctly. So, it may look strange but it does work.
Admin
"Are you dead?"
Questions that can be answered only one way.
Admin
Admin
sounds like a great method you got there to track down bugs... maybe you can add your entry to wiki's anti-pattern article, they are lacking a bit of examples for their "Programming by Accident" article.
http://en.wikipedia.org/wiki/Anti-pattern
Admin
You sometime have to cast a null for overload resolution. Nothing funny about that.
Admin
Actually, casting a null to something concrete is perfectly valid. If you have overloaded methods, you'll have to do something like that.
Now, the most hilarious problem is that [x].equals(null) will thros a NullPointerException every damn time [x] is actually null. Plus "this" can never be null! So it's a great big unnecessary test that fails in so many ways...
Admin
Heh - only just spotted that only "featured" comments were shown. Ignore my repetition of every damn sane point made in this thread.
Admin
Aha! Defensive programming has been reinvented at last...
Admin
Some gems I have come across which I'd like to share:
something = NULL; something->hello();
something = something_else; // stuff happens here something = NULL; delete something;
Admin
I have one to share, too. I found this one more than once, so it didn't seem to be an accident.
if (s instanceof String && s != null) { //dosomething }Admin
Regarding: Warning.showWarning((JFrame) null, title, msg);
No WTF there. Depending on the implementation of showWarning, this may work and may even be necessary.
If you have two overloaded methods with the same name, for example
void showWarning(JFrame frame, String title, String msg); void showWarning(JWindow frame, String title, String msg);
then, if you want to pass null and this is an acceptable value, you need to use an explicit cast to tell the compiler which of the two methods to invoke. Otherwise, the method to invoke is ambiguous.
Admin
I think The Real WTF is that nobody has commented on the first call to showWarning() casting null to a JFrame.
Admin
As stated many times, that can be necessary to remove ambiguity in the presence of method overloading.
My personal WTF is that I had to write that explanation, even though several other readers had already pointed it out. I guess I need to learn how to click on the "All comments" link ;)