The Daily WTF: Curious Perversions in Information Technology

boog · 2011-08-31 Reply Admin

Grim:
Alex:
No WTF to be found here.
I concur.

You do realize this code came from a reimplementation of C# generic collections, don't you? It's a WTF regardless of what any of us think about null-checking.

Grim:
The "== false" is a littly iffy...

Ha! I'm writing that one down... :)

Grim:
...but argument validation is fundamental.

So is testing. If an argument should never be null, your testing should ensure that the variable to be passed in is never null. You shouldn't rely on the API to tell you how you break your code.

2011-08-31 Reply Admin

So, in a debug build the code will show an assertion dialog and in release build it will throw.

What was the WTF again?

boog · 2011-08-31 Reply Admin

midas:
Severity One:
Anyway, the way I'm interpreting the above is not that you should always check parameters, but that the appropriate exception should be thrown if erroneous parameters are passed. And with a null object, you do get the NullPointerException. It's just that it's thrown by the virtual machine, instead of your own code.
However, this WTF was written i C#.

Glad to see you on the "it's-a-WTF" bandwagon. ;)

midas:
C# has ArgumentNullException, which would be even more appropriate than NullReferenceException.
I think we can all agree on that doing a check and throwing an ArgumentNullException is at least NOT A WTF. Right?

More specifically, we can all agree that Microsoft clearly had different intentions with C# than Sun had with Java. So maybe the developer is following recommended practices, but really, would it ever occur to you to put this logic into its own class?

midas:
Then we can argue forever if these checks are actually worth the effort and extra LOC or not...

*big grin*

frits · 2011-08-31 Reply Admin

boog:
Grim:
Alex:
No WTF to be found here.
I concur.
You do realize this code came from a reimplementation of C# generic collections, don't you?

That was an uncorroborated accusation by the n00b OP.

Severity One · 2011-08-31 Reply Admin

QJo:
I see you've changed your position from:
"But I refuse to check parameters passed to my API methods to make sure that the other developer isn't a trained chimp. If I write in the JavaDocs that you must pass a non-null instance of ClassX, you must pass a non-null instance of ClassX. You must not pass an instance of ClassY, except if it's derived from ClassX, and you must most definitely not pass null. If you do pass null, I can guarantee you that you get a NullPointerException at some point in the code. "

to:

"There are clear examples where checking parameters is useless, because you'll get exactly the same exception two lines down anyway. And there are clear examples where not checking parameters is like giving a hand grenade to a baby and saying "remember, don't pull out the pin"."

Huh? In what way are these statements mutually exclusive? It's not what you're saying per se, but given that the two statements do not contradict one another, I find the qualification 'moved' a bit strong.

I still think it's useless to check each and every parameter in case my employer decides to outsource certain work not to local firms like they do now, but to the zoo. I also think it's my responsibility not to make a mess. The second paragraph is a clarification, which was apparently needed.

But oh, how I wish I were a clever person like you so that I can always tell whether what I've programmed is going to be the equivalent of a hand-grenade with a baby clutching it. In point of fact I know that my judgment is imperfect, and understanding this fact (and understanding the fact that others may likewise have a less-than-perfect sense of discrimination) I would prefer that programs with which I am involved should espouse the philosophy of "safety first", and when in doubt put a parameter check in. Not to do so because you think you know better may not be laziness then, but it's pretty close to foolhardiness.

Sarcasm is an art, the talent of which is given to as few people as is the ability to properly understand a text. So perhaps you shouldn't try and waste your energy on it, because you don't manage the latter too well either.

I think I've quite effectively shown that always checking all parameters, regardless the circumstances, is not good practice, but religion. Call it cargo-culture programming: doing something because you think you're supposed to do it, without really understanding why.

Yes, I am a clever programmer, and I'm just as imperfect as anybody else. What makes me a good programmer is that I know my strengths and weaknesses, and which things work, and which don't, and what the things are you need to look out for.

2011-08-31 Reply Admin

QJo:
Pauladin:
A good programmer is someone who always looks both ways before crossing a one-way street.

Doug Linder
+1 QFT

only both ways? what about up and down and back and forwards?

2011-08-31 Reply Admin

I'm already far beyond your level of skill. Come back when you know that the rockstar, was in fact right, kiddie.

boog · 2011-08-31 Reply Admin

B00nbuster:
I'm already far beyond your level of skill.

Clearly. Because you say so, after all.

B00nbuster:
Come back when you know that the rockstar, was in fact right, kiddie.

Hey, keep the overwhelming evidence and well-thought-out arguments coming. You just might convince me.

hoodaticus · 2011-08-31 Reply Admin

Severity One:
I think I've quite effectively shown that always checking all parameters, regardless the circumstances, is not good practice, but religion. Call it cargo-culture programming: doing something because you think you're supposed to do it, without really understanding why.
Yes, I am a clever programmer, and I'm just as imperfect as anybody else. What makes me a good programmer is that I know my strengths and weaknesses, and which things work, and which don't, and what the things are you need to look out for.

+1 for pragmatism, and +1 for the cargo cult analogy.

Checking every parameter throughout your framework causes slower performance, lower quality code, and more bugs if your time budget is constant. Like everything else in life, pragmatism is called for, and the You'reNotGonnaNeedIt (YNGNI) principle applies.

hoodaticus · 2011-08-31 Reply Admin

If some of these developers were to design a real-world lock for a door, they would have sensors to warn the user if they tried to stick something in the hole that isn't a key...

boog · 2011-08-31 Reply Admin

hoodaticus:
If some of these developers were to design a real-world lock for a door, they would have sensors to warn the user if they tried to stick something in the hole that isn't a key...

More accurate analogy: they would have sensors to warn the user whenever there wasn't a key in the lock.

Sutherlands · 2011-08-31 Reply Admin

hoodaticus:
Checking every parameter throughout your framework

Are we including private methods? I don't think we need to check every input to private methods.

hoodaticus:
causes slower performance,

But not enough to matter.

hoodaticus:
lower quality code,

Citation needed

hoodaticus:
and more bugs if your time budget is constant.

If better exceptions allows me to find what bugs are there faster, I can get rid of them faster. Writing a couple lines at the top of some methods takes considerably less time than hunting down a couple bugs (or even designing the workflow).

Sutherlands · 2011-08-31 Reply Admin

Severity One:
It's one of the reasons why communicating between Java and C# using SOAP, particularly when a date is involved, is such a hassle.
(Although it ought to be mentioned that SOAP does allow fields to be null, or to be not present, which I don't believe you can easily express in C# dates.)

As mentioned before, in C# you can use Nullable<DateTime> or DateTime? to get the desired behavior. You can also use:

[XmlElement] DateTime ParameterName { get; set; }

bool ParameterNameSpecified { get; set; }

(I forget what the second param should be marked up as) The above will make ParameterName optional, and ParameterNameSpecified will say whether it was in the string that was deserialized, or whether to serialize the parameter (depending on what operation you're doing).

hoodaticus · 2011-08-31 Reply Admin

Sutherlands:
hoodaticus:
causes slower performance,
But not enough to matter.
hoodaticus:
lower quality code,
Citation needed
hoodaticus:
and more bugs if your time budget is constant.
If better exceptions allows me to find what bugs are there faster, I can get rid of them faster. Writing a couple lines at the top of some methods takes considerably less time than hunting down a couple bugs (or even designing the workflow).

How much slower it makes the code depends on how chunky or chatty it is and how much more bloated it is (thus expelling crap from L1 and L2 caches and preventing inlining). And I need no citation to note that if your time budget is constant, the guy who has less to type is going to have more time to think.

You raise an interesting point: "If better exceptions allows me to find what bugs are there faster, I can get rid of them faster." The key term in that sentence is "IF". If you KNOW you're going to need a certain argument to be checked, then check it.

Doing it always is fanaticism, which has been defined as "continuing to zealously carry out a practice the purpose of which has long been forgotten".

2011-08-31 Reply Admin

Well, sorry to say that, but the real WTF here is that the author of this story really is clueless about how clueless he is. It's nothing bad to be inexperienced, but it's best to be extra cautious with your judgments then.

The reason for replacing future NullReferenceException with ArgumentExceptions thrown early on has already been explained several times, and AssertionSomething attributes are probably there to avoid annoying warnings by Resharper. And they exist exactly for that reason. (Hey, author, did you check them up or decided it's enough to guess?) All in all, standard good practice :)

Sutherlands · 2011-08-31 Reply Admin

hoodaticus:
How much slower it makes the code depends on how chunky or chatty it is and how much more bloated it is (thus expelling crap from L1 and L2 caches and preventing inlining). And I need no citation to note that if your time budget is constant, the guy who has less to type is going to have more time to think.
You raise an interesting point: "If better exceptions allows me to find what bugs are there faster, I can get rid of them faster." The key term in that sentence is "IF". If you KNOW you're going to need a certain argument to be checked, then check it.

Doing it always is fanaticism, which has been defined as "continuing to zealously carry out a practice the purpose of which has long been forgotten".

Perhaps our experiences are different. The projects I work on are easily dominated by the database and webservice calls. The time of a couple checks is nothing compared to that. Also, a lot of the projects we work on are "make this relatively small change, then deploy the new DLL to all 20 web services." Deployment time greatly overshadows development time on the vast majority of projects, so I can easily have an extra 30s (or 30min, if I want) to add those checks.

2011-08-31 Reply Admin

hoodaticus:
Severity One:
I think I've quite effectively shown that always checking all parameters, regardless the circumstances, is not good practice, but religion. Call it cargo-culture programming: doing something because you think you're supposed to do it, without really understanding why.
Yes, I am a clever programmer, and I'm just as imperfect as anybody else. What makes me a good programmer is that I know my strengths and weaknesses, and which things work, and which don't, and what the things are you need to look out for.
+1 for pragmatism, and +1 for the cargo cult analogy.

Checking every parameter throughout your framework causes slower performance, lower quality code, and more bugs if your time budget is constant. Like everything else in life, pragmatism is called for, and the You'reNotGonnaNeedIt (YNGNI) principle applies.

Do you want to optimize for developer time or run time? If the latter, yes, you need to spare the parameter checks and spend a lot of time getting things right without exceptions. Get in the time machine and go back to the land of memory-is-a-scarce-resource and take a few lessons, they know how it's done.

If you care more about developer time, just check the arguments and throw informative exceptions.

and more bugs if your time budget is constant.

How you figgah? Finding bugs faster means more bugs are discovered sooner, which means fewer bugs, I'd think.

2011-08-31 Reply Admin

hoodaticus:
Doing it always is fanaticism, which has been defined as "continuing to zealously carry out a practice the purpose of which has long been forgotten".

I think you've got your defintion the wrong way around. That's like saying "this here is an automobile, which has been defined as a '1969 Volkswagen Beetle'."

hoodaticus · 2011-08-31 Reply Admin

trtrwtf:
hoodaticus:
Doing it always is fanaticism, which has been defined as "continuing to zealously carry out a practice the purpose of which has long been forgotten".

I think you've got your defintion the wrong way around. That's like saying "this here is an automobile, which has been defined as a '1969 Volkswagen Beetle'."

Not my definition. I was paraphrasing some dude named George Santayana.

hoodaticus · 2011-08-31 Reply Admin

Akismet:
hoodaticus:
Severity One:
I think I've quite effectively shown that always checking all parameters, regardless the circumstances, is not good practice, but religion. Call it cargo-culture programming: doing something because you think you're supposed to do it, without really understanding why.
Yes, I am a clever programmer, and I'm just as imperfect as anybody else. What makes me a good programmer is that I know my strengths and weaknesses, and which things work, and which don't, and what the things are you need to look out for.
+1 for pragmatism, and +1 for the cargo cult analogy.

Checking every parameter throughout your framework causes slower performance, lower quality code, and more bugs if your time budget is constant. Like everything else in life, pragmatism is called for, and the You'reNotGonnaNeedIt (YNGNI) principle applies.

Do you want to optimize for developer time or run time? If the latter, yes, you need to spare the parameter checks and spend a lot of time getting things right without exceptions. Get in the time machine and go back to the land of memory-is-a-scarce-resource and take a few lessons, they know how it's done.

If you care more about developer time, just check the arguments and throw informative exceptions.

and more bugs if your time budget is constant.

How you figgah? Finding bugs faster means more bugs are discovered sooner, which means fewer bugs, I'd think.

I'm trying to optimize both. I'm pretty sure the sweet spot is somewhere less than "check every argument", which is as extremist as you can get. More code means more bugs, btw.

Addendum (2011-08-31 14:39): There are two camps on this thread. One says "always validate every public parameter without thinking about it". The other side says "Yeah, but think about it first".

If you have a method that does this:

void foo(MyClass a) { a.InstanceMethod(); }

There is nothing gained by checking a for null - it's going to blow up right there in the called method, the same number of lines-in that it would have blown up anyway. The stack trace will be almost identical. So don't check it here.

All I want is people to think about what they're doing rather than mindlessly following some religious dogma. WWJD.

hoodaticus · 2011-08-31 Reply Admin

Akismet:
Get in the time machine and go back to the land of memory-is-a-scarce-resource and take a few lessons, they know how it's done.
If you care more about developer time, just check the arguments and throw informative exceptions.

In case you haven't noticed, processor speeds have stopped going up, so your take-performance-for-granted mindset is a little, how do we say, "September 10th". Code bloat reduces CPU cache efficiency and slows everything down.

At some point, you have to code for performance, or no one will want your code and you won't need any developer time at all.

2011-08-31 Reply Admin

boog:
midas:
Severity One:
Anyway, the way I'm interpreting the above is not that you should always check parameters, but that the appropriate exception should be thrown if erroneous parameters are passed. And with a null object, you do get the NullPointerException. It's just that it's thrown by the virtual machine, instead of your own code.
However, this WTF was written i C#.
Glad to see you on the "it's-a-WTF" bandwagon. ;)
midas:
C# has ArgumentNullException, which would be even more appropriate than NullReferenceException.
I think we can all agree on that doing a check and throwing an ArgumentNullException is at least NOT A WTF. Right?
More specifically, we can all agree that Microsoft clearly had different intentions with C# than Sun had with Java. So maybe the developer is following recommended practices, but really, would it ever occur to you to put this logic into its own class?

midas:
Then we can argue forever if these checks are actually worth the effort and extra LOC or not...
*big grin*

I would definitly put such a check in public methods that I knew would be widely used. Otherwise I often take the shortcut and skip the test, because I'm lazy. (And, now and then, some NullReferenceException happens to testers, and I curse myself not to have written that check.) That's not the point however, the point I've been trying to argue for all along is that THESE CHECKS ARE NOT A WTF.

hoodaticus · 2011-08-31 Reply Admin

midas:
boog:
midas:
Severity One:
Anyway, the way I'm interpreting the above is not that you should always check parameters, but that the appropriate exception should be thrown if erroneous parameters are passed. And with a null object, you do get the NullPointerException. It's just that it's thrown by the virtual machine, instead of your own code.
However, this WTF was written i C#.
Glad to see you on the "it's-a-WTF" bandwagon. ;)
midas:
C# has ArgumentNullException, which would be even more appropriate than NullReferenceException.
I think we can all agree on that doing a check and throwing an ArgumentNullException is at least NOT A WTF. Right?
More specifically, we can all agree that Microsoft clearly had different intentions with C# than Sun had with Java. So maybe the developer is following recommended practices, but really, would it ever occur to you to put this logic into its own class?

midas:
Then we can argue forever if these checks are actually worth the effort and extra LOC or not...
*big grin*

I would definitly put such a check in public methods that I knew would be widely used. Otherwise I often take the shortcut and skip the test, because I'm lazy. (And, now and then, some NullReferenceException happens to testers, and I curse myself not to have written that check.) That's not the point however, the point I've been trying to argue for all along is that THESE CHECKS ARE NOT A WTF.

Agreed! They're "good". But there's a non-zero opportunity cost in doing it, so blindly doing it everywhere is dumb. But even then, doing it all the time is not a WTF, it's just... dumb, as shown below:

void foo(MyC

Addendum (2011-08-31 17:48): void foo(MyClass a) { if (a == null) throw new Blah(); a.Method(); }

Useless under all circumstances.

boog · 2011-08-31 Reply Admin

midas:
That's not the point however, the point I've been trying to argue for all along is that THESE CHECKS ARE NOT A WTF.

While I've suggested that null checking is rarely necessary, I never meant to imply that the practice is a WTF, nor do I think anyone else has.

However, I do believe the featured code is a WTF - it's not the idea that offends me, it's the implementation.

2011-08-31 Reply Admin

boog:
hoodaticus:
If some of these developers were to design a real-world lock for a door, they would have sensors to warn the user if they tried to stick something in the hole that isn't a key...
More accurate analogy: they would have sensors to warn the user whenever there wasn't a key in the lock.

Is there a way to make a method throw an exception when it's not used?

Seriously though, why are some many assuming that those not finding this a WTF are for checking every single parameter, everywhere? It's stupid.

Check the parameters on public methods when you must, and be wary that you might be hiding other problems, maybe fundamental, in your code. Displaying a message about why you're throwing the exception might be... basic civility. Hand-holding as a bonus, not as a purpose, if you will.

Too many assumptions in here about this Rockstar, and how the code was used.

Or is the WTF that's in a class? Called Guard? Not correct exception thrown when null or empty?

WTF!?

hoodaticus · 2011-08-31 Reply Admin

Burt R:
Check the parameters on public methods when you must

Duh. What I don't get is why this simple proposition is so controversial. But then, this is thedailywtf.com.

2011-08-31 Reply Admin

The obvious exception is when evaluating BOOL returns from a WIN API function.

Otherwise generally not needed but hardly idiotic.

2011-09-01 Reply Admin

hoodaticus:
Spewin Coffee:
The real problem is that there is an ERP system written in C#.
There is coffee on my monitor.
There are ERP systems written in FOXPRO!

vomits

pants

yes ... I know that for a fact sobs

CAPTCHA: inhibeo - "inhibeo those foxpro coders before they make another bomb"

2011-09-01 Reply Admin

midas:
boog:
As for the discussion, I'm going to have to agree with Severity One. Mainly because I don't think null-checking is a form of sanity-checking, since calling a method on a null object is never not insane. That's why Java and C# automatically freak the fuck out* when it happens.
*I admit this is a slight exaggeration for "throw a NullPointerException"

First, Microsoft is a "WTF" today.

Fixed for you .. if you go to Microsoft for coding standards, start by asking yourself how and why your windows crashed or how and why MS Office takes so much RAM *before* loading anything useful.

2011-09-01 Reply Admin

boog:
midas:
That's not the point however, the point I've been trying to argue for all along is that THESE CHECKS ARE NOT A WTF.
While I've suggested that null checking is rarely necessary, I never meant to imply that the practice is a WTF, nor do I think anyone else has.
However, I do believe the featured code is a WTF - it's not the idea that offends me, it's the implementation.

What exactly is wrong with the implementation?

2011-09-01 Reply Admin

L.:
midas:
boog:
As for the discussion, I'm going to have to agree with Severity One. Mainly because I don't think null-checking is a form of sanity-checking, since calling a method on a null object is never not insane. That's why Java and C# automatically freak the fuck out* when it happens.
*I admit this is a slight exaggeration for "throw a NullPointerException"

First, Microsoft is a "WTF" today.

Fixed for you .. if you go to Microsoft for coding standards, start by asking yourself how and why your windows crashed or how and why MS Office takes so much RAM *before* loading anything useful.

Well, since XP and forward, Windows usually crash because of faulty drivers, and I've never noticed MSOffice taking much RAM - I have, however, noticed that Word etc starts significantly faster than any competitors I've tried.

However, I understand the point your trying to make - and I agree that Microsoft write pretty buggy products, however, this is an effect of a culture of, well, not fixing bugs, rather than actually writing bad code.

2011-09-01 Reply Admin

midas:
L.:
midas:
boog:
As for the discussion, I'm going to have to agree with Severity One. Mainly because I don't think null-checking is a form of sanity-checking, since calling a method on a null object is never not insane. That's why Java and C# automatically freak the fuck out* when it happens.
*I admit this is a slight exaggeration for "throw a NullPointerException"

First, Microsoft is a "WTF" today.

Fixed for you .. if you go to Microsoft for coding standards, start by asking yourself how and why your windows crashed or how and why MS Office takes so much RAM *before* loading anything useful.

Well, since XP and forward, Windows usually crash because of faulty drivers, and I've never noticed MSOffice taking much RAM - I have, however, noticed that Word etc starts significantly faster than any competitors I've tried.

However, I understand the point your trying to make - and I agree that Microsoft write pretty buggy products, however, this is an effect of a culture of, well, not fixing bugs, rather than actually writing bad code.

I'll say writing good code does not include writing buggy code.

The behaviour of quite a few softwares shows clearly bad code causing the bugs (you know Skype, right ?) and there's some of that in MS end user stuff. -> I hate Excel, and I've heard countless stories of it choking on 50+meg files (alright it's a bad idea to not use a db at that point and I wouldn't ever do that but ...)

I'm not saying it's possible to avoid every corner case on the first iteration of the code, but avoiding a whole lot of them (including null pointer exceptions) isn't that hard at all.

2011-09-01 Reply Admin

L.:
midas:
L.:
midas:
boog:
As for the discussion, I'm going to have to agree with Severity One. Mainly because I don't think null-checking is a form of sanity-checking, since calling a method on a null object is never not insane. That's why Java and C# automatically freak the fuck out* when it happens.
*I admit this is a slight exaggeration for "throw a NullPointerException"

First, Microsoft is a "WTF" today.

Fixed for you .. if you go to Microsoft for coding standards, start by asking yourself how and why your windows crashed or how and why MS Office takes so much RAM *before* loading anything useful.

Well, since XP and forward, Windows usually crash because of faulty drivers, and I've never noticed MSOffice taking much RAM - I have, however, noticed that Word etc starts significantly faster than any competitors I've tried.

However, I understand the point your trying to make - and I agree that Microsoft write pretty buggy products, however, this is an effect of a culture of, well, not fixing bugs, rather than actually writing bad code.

I'll say writing good code does not include writing buggy code.

The behaviour of quite a few softwares shows clearly bad code causing the bugs (you know Skype, right ?) and there's some of that in MS end user stuff. -> I hate Excel, and I've heard countless stories of it choking on 50+meg files (alright it's a bad idea to not use a db at that point and I wouldn't ever do that but ...)

I'm not saying it's possible to avoid every corner case on the first iteration of the code, but avoiding a whole lot of them (including null pointer exceptions) isn't that hard at all.

I have no idea where you are trying to take this discussion. While you complain that MS writes crappy code, you complain about their guidelines encouraging checks that makes locating bugs easier? This doesn't make any sense.

2011-09-01 Reply Admin

Suppose you are an API developer . And someone else uses your API . Now which of these sound better ?

Hey ,I got a NullPointerException when i called your method . Description says "blah blah blah" . You should fix it .

vs

Hey I got this ArgumentNullException when I called your method . The description says "argument foo for the method cannot be null" ........ <short stop> . Nevermind , problem in the local system , I think .

hoodaticus · 2011-09-01 Reply Admin

L.:
hoodaticus:
Spewin Coffee:
The real problem is that there is an ERP system written in C#.
There is coffee on my monitor.
There are ERP systems written in FOXPRO!

vomits

pants

yes ... I know that for a fact sobs

CAPTCHA: inhibeo - "inhibeo those foxpro coders before they make another bomb"

LOL! I know, right! I've got a few gray hairs with @productName written all over them!

token_woman · 2011-09-01 Reply Admin

pedantic:
bits:
I minus well not comment on the grammer - it's a mute point.
moot

gramar

Severity One · 2011-09-01 Reply Admin

Akismet:
Do you want to optimize for developer time or run time?

Didn't I say I use Java? That should answer your question. :)

But yeah, as has been pointed out several times before, and equally often ignored: checking all parameters, always, without wondering why, doesn't make sense.

boog · 2011-09-01 Reply Admin

midas:
boog:
midas:
That's not the point however, the point I've been trying to argue for all along is that THESE CHECKS ARE NOT A WTF.
While I've suggested that null checking is rarely necessary, I never meant to imply that the practice is a WTF, nor do I think anyone else has.
However, I do believe the featured code is a WTF - it's not the idea that offends me, it's the implementation.

What exactly is wrong with the implementation?

Among other things, its very existence. If you want to check for null, then just check for null. At least then you're throwing the exception from the right class and method.

2011-09-01 Reply Admin

zAPP:
An alternate explanation:
[The problems with null references].
The problem with the null references problem is that you can't just remove null references.

Because how would you for example implement a tree structure if you can't set children to null. (You need to set the children to null at the bottom of the tree).

I think a good solution would be to have 2 reference types. One which can be null, and one which can't. Then the type of the reference will indicate if it can be null or not. (And this should be verified at compile time).

You could solve it by requiring a valid null-value for everything. You know, like an integer can actually be 0 and you can check if it is, by comparing it with 0.
You would have to define a Null-state of each class that will get created with the first object of that class. Pointers at these objects, that are set to NULL, would point to that NULL-object instead. You could then still access it without an exception and have the predefined results.

The problem with this approach (if I understand what you're saying) is that it hides coding errors and makes them even harder to find than they would be with a NullPointerException.

Let's say that you have, effectively. (Note, all my examples will be in Java, as I don't know C#.)

Foo foo = FooNullObject;

instead of

Foo foo = null; // or just never set to anything at all

The real problem isn't that you get the NPE at runtime. That's just a symptom. It sucks, but at least it's a highly visible symptom, and it tells you what the problem was and gives you some idea where it occurred.

Now, if we have the Null Object instead, when we call foo.doStuff(), we won't get the NPE. We'll just get "nothing happening." A running total will have 0 added to it, or an empty list will be iterated over, etc. But this too is a symptom; it's just a much more diabolical and hard-to-detect-and-analyze symptom.

There was supposed to be an "actual" Foo object with actual values, but instead there's just this dummy placeholder that's nigh indistinguishable from the one that was supposed to be there, until much further down the line when the end-of-month reports don't add up.

Now, if I understand the concept of the "non-nullable type" that others have been advocating, it would be something like this.

Assume Java supports the syntax Foo? to indicate that the type is the non-nullable version of Foo.

Foo foo1; // legal
Foo foo2 = null; // legal
Foo foo3 = new Foo(); // legal
final Foo foo4 = new Foo(); // legal

Foo? foo5; // compile error
Foo? foo6 = null; // compile error
Foo? foo7 = foo2; // compile error
Foo? foo8 = foo3; // compile error
Foo? foo9 = foo4; // legal
Foo? foo10 = new Foo(); // legal

Foo foo11 = foo10; // legal

In other words, the compiler won't let you have a Foo? reference that's not pointing to an actual Foo object.

There are some details that would be up to the per-language implementation, such as whether the compiler can tell that a non-file Foo has been assigned and not reset to null, so could be legal for a Foo? (contrary to the above example), or whether explicit casting from a Foo to a Foo? would be allowed. "Clever" programmers will still find ways to screw it up, but something like this would protect against NPEs and unexplained "empty" values by catching a lot of the sources of these problems at compile time, and it lets us forgo a lot of the null checks we might otherwise put in place.

2011-09-02 Reply Admin

hoodaticus:
Akismet:
Get in the time machine and go back to the land of memory-is-a-scarce-resource and take a few lessons, they know how it's done.
If you care more about developer time, just check the arguments and throw informative exceptions.
In case you haven't noticed, processor speeds have stopped going up, so your take-performance-for-granted mindset is a little, how do we say, "September 10th". Code bloat reduces CPU cache efficiency and slows everything down.

At some point, you have to code for performance, or no one will want your code and you won't need any developer time at all.

THIS . is the future.

If businesses can spend millions each year to cut back on DC costs, believe me they'd love to spend millions each year on "green" applications, which would evidently also be better,faster,stronger ...

Anyway I don't like to code shit, and I'm not planning on coding bugs either, so do what floats your boat, check everything against anything and be happy if that's your way to go - your code will still suck when you're finished but that's your problem.

And then, the day companies care about developper time, they'll hire good programmers and pay them a f*ton instead of hiring 500 indians to do it slower (than one good coder) and worse for more money .

2011-09-02 Reply Admin

hoodaticus:
L.:
hoodaticus:
Spewin Coffee:
The real problem is that there is an ERP system written in C#.
There is coffee on my monitor.
There are ERP systems written in FOXPRO!

vomits

pants

yes ... I know that for a fact sobs

CAPTCHA: inhibeo - "inhibeo those foxpro coders before they make another bomb"
LOL! I know, right! I've got a few gray hairs with @productName written all over them!

Eh .. If we're talking about the same damn stuff, you may know they also have parts in .... delphi woooohoooo ! .

Why oh why did anyone think C wasn't good enough ... most of the languages since are so much worse it makes me wonder why someone bothered inventing them.

2011-09-02 Reply Admin

Severity One:
Akismet:
Do you want to optimize for developer time or run time?
Didn't I say I use Java? That should answer your question. :)
But yeah, as has been pointed out several times before, and equally often ignored: checking all parameters, always, without wondering why, doesn't make sense.

You use Java .. I guess you're optimizing for nothing then .

Java is slower run time than C / C++ (duh)

Java is longer dev time than quite a few others, due to so many fail libraries that you eventually have to fix anyway because the software architect thought it was great to build everything from existing blocks ... for dev time ... lol

Java is optimized for one thing : enabling a swarm of bad coders to produce 'working' software, and it does it quite well, as we have all seen many largely overweight java apps actually running (although they're full of crap or ide-generated copy-paste type of stuff).

And that's why everyone's there talking about exceptions and stuff and shared API's used by monkeys etc.

Java has become a fail in itself BECAUSE of the tetris dev model (you know, sometimes if you don't make or check the blocks, some lines will be incomplete .. and filling them is damn hard at the very least) - and don't even try to argue, I'm pretty sure you never read hibernate source code anyway.

Severity One · 2011-09-02 Reply Admin

L.:
You use Java .. I guess you're optimizing for nothing then .
Java is slower run time than C / C++ (duh)

Java is longer dev time than quite a few others, due to so many fail libraries that you eventually have to fix anyway because the software architect thought it was great to build everything from existing blocks ... for dev time ... lol

Java is optimized for one thing : enabling a swarm of bad coders to produce 'working' software, and it does it quite well, as we have all seen many largely overweight java apps actually running (although they're full of crap or ide-generated copy-paste type of stuff).

And that's why everyone's there talking about exceptions and stuff and shared API's used by monkeys etc.

Java has become a fail in itself BECAUSE of the tetris dev model (you know, sometimes if you don't make or check the blocks, some lines will be incomplete .. and filling them is damn hard at the very least) - and don't even try to argue, I'm pretty sure you never read hibernate source code anyway.

If you come into sunlight, do you turn into stone? Because you make an excellent troll.

I'm not even going to argue this. I know what I write in Java, and how well it works. As you should have figured out by now, I have little patience for people who make a mess of code - and, as it happens, for people who throw up a lot of uncorroborated claims that one particular platform would somehow induce bad coding practices.

2011-09-02 Reply Admin

How can you "handle the problem"? make up a pointer to some random thing?

Passing an argument that's out of bounds for the contract can't possibly be solved from inside the library. It's the caller's problem, and the sooner the caller finds out about it the better.

Ada now allows you to say in the type system that a pointer mustn't be null: "type Foo_P is not null access Foo;" for example.

2011-09-02 Reply Admin

I'll give you a comparison you know : Linux vs Windows.

Windows is "easy" -> Windows users have a limited need to learn how to use their computer to actually use it -> they have limited control/understanding of their computer

Linux is "hard" -> Linux users are forced to learn much more in order to use their computer (yes even ubuntu can be a tiny little bit hard)-> they have more control/understanding of their computer

In the same way, Java makes lots of things easy (GC, private vars / methods, syntax constraints, etc.) -> Java programmers are guided by the compiler /assisted by the JVM into producing "working" code.

Compare that with C, where you get like no guidance/assistance -> C programmers who make "working" code have to learn much more before doing so

The end result is that in order to produce a "working" program in Java, you will require less skill, and will thus be more easily qualified as a "usable" programmer, and will thus in the end produce lower quality code on average.

2011-09-02 Reply Admin

L.:
You use Java .. I guess you're optimizing for nothing then .
Java is slower run time than C / C++ (duh)

Java is longer dev time than quite a few others, due to so many fail libraries that you eventually have to fix anyway because the software architect thought it was great to build everything from existing blocks ... for dev time ... lol

After reading this and a few of your other posts, I have one question: Are you a horribly unimaginative troll, or simply a retarded C fanboy who's having a little hissy fit because your tampon got stuck crossways when you learned that the world of software development is ever changing and won't settle into a permanent orbit around the mad rock star skilz you imagine you have?

2011-09-02 Reply Admin

L.:
I'll give you a comparison you know : Linux vs Windows.
blah blah nonsense blah

You poor, sad little man.

2011-09-03 Reply Admin

Only logically incorrect code throws NPE's. Since you presumably write your code to be correct, no NPE's are expected. However mistakes are made so then you let the UNexpected errors (in the form of exceptions) bubble up and become visible. Don't catch NPE's. That is at best, papering over poor worksmanship.

2011-09-03 Reply Admin

http://msdn.microsoft.com/en-us/library/system.string.isnullorempty.aspx LOL standard classes?

2011-09-05 Reply Admin

jverd:
L.:
You use Java .. I guess you're optimizing for nothing then .
Java is slower run time than C / C++ (duh)

Java is longer dev time than quite a few others, due to so many fail libraries that you eventually have to fix anyway because the software architect thought it was great to build everything from existing blocks ... for dev time ... lol

After reading this and a few of your other posts, I have one question: Are you a horribly unimaginative troll, or simply a retarded C fanboy who's having a little hissy fit because your tampon got stuck crossways when you learned that the world of software development is ever changing and won't settle into a permanent orbit around the mad rock star skilz you imagine you have?

I would gladly troll you but unfortunately this requires a bit of cooperation on your part.

The world of dev is ever changing ... true and false tbh ... most applications are clones of repeats of duplicated of copies of an imitation .(and they're even bad at it)

Everything is changing, always, and your beloved Java is already obsolete (phew about time ...)

Finally, I'm not as good with a guitar as I'd like to be and it's really unfriendly of you to point it out to me ... I'll go cry under the shower now.

The Rockstar's Guard

Leave a comment on “The Rockstar's Guard”