- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- 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
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?
Admin
Admin
Admin
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.
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.
Admin
only both ways? what about up and down and back and forwards?
Admin
I'm already far beyond your level of skill. Come back when you know that the rockstar, was in fact right, kiddie.
Admin
Admin
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.
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...
Admin
Admin
Admin
[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).
Admin
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".
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 :)
Admin
Admin
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.
How you figgah? Finding bugs faster means more bugs are discovered sooner, which means fewer bugs, I'd think.
Admin
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'."
Admin
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
However, I do believe the featured code is a WTF - it's not the idea that offends me, it's the implementation.
Admin
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!?
Admin
Admin
The obvious exception is when evaluating BOOL returns from a WIN API function.
Otherwise generally not needed but hardly idiotic.
Admin
vomits
pants
yes ... I know that for a fact sobs
CAPTCHA: inhibeo - "inhibeo those foxpro coders before they make another bomb"
Admin
Admin
What exactly is wrong with the implementation?
Admin
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.
Admin
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.
Admin
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.
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 .
Admin
Admin
gramar
Admin
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.
Admin
Admin
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#.)
instead of
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.
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.
Admin
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 .
Admin
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.
Admin
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.
Admin
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.
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.
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.
Admin
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?
Admin
You poor, sad little man.
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.
Admin
http://msdn.microsoft.com/en-us/library/system.string.isnullorempty.aspx LOL standard classes?
Admin
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.