> What happened to the rest of the quote? "That’s not to say > that null checks are wrong. If a vendor gives you a > library that can return null, you’re obliged to check for > null. And, if people are passing null all over the place > in your code, it makes sense to keep putting some null > checks in, but, you know what? That just means that you’re > dealing with bad code: you're dealing with code where > people are actively making extra work for themselves and > making code brittle in the process."
My intention was that say that it's the passing of null that's a problem, not checking for it. I think that pervasive checking is a symptom, though. To me, most of the time its a symptom that indicates that things could be better.
> How is that not a generalization on your part? People pass > null == bad code is what I see there. As I said in a > previous post, I've had several people come by and talk to > me about this today and what they got from it is "Don't > check for null".
I think that the thing is, I've seen better code. It's very nice when a team can have a common understanding that they won't pass null. It makes the code cleaner, you only have to check at the edges. Is this universally applicable? Probably not, but to me, it's hard to say that a system where people have to be cautious about every reference is good, especially when a convention from the beginning of development could have made things better.
> I've also had to fix plenty of code that > would qualify as "stupid free" because it didn't check for > null and then subsequently crashed, telling me that an > instance of an object was not instantiated. So it had to > get fixed. And, honestly, I don't have the time to > refactor an entire code base to take care of an issue > where somebody didn't make sure their input was valid, so > the input gets validated in that instance where it is > crashing. If I had to refactor every codebase I came > across to be what I would consider "right", well, I don't > want to work that long. :-(
Yes, it there's a lot of existing code out there. Not all of it will ever be fixed.
> There are also several instances in code I work on where > null is a valid occurence and very different from an > object, such as in your array example, that has no > entries. In these cases we had to reduce overhead (mostly > free memory that containted nothing but lots of empty > structures) and pick up some performance. I keep hearing > how arguments like these are red herrings and straw men, > yet when I implement these changes I get from 15 - 60% > performance improvements. Projects like this are why I > agree with your assertion in theory but not in practice, > as I also said.
What about a singleton null object? Create a static instance and refer to it every place you would have a null?
> > And yeah, these things can be hard to talk about. > Especially when you call people stupid. Or, maybe, more > technically, tell people they write code that resides in a > stupid zone. I have, and will continue to write, a lot of > code that you would probably consider stupid, simply > because I don't know where or how it is going to get used. > Most of the code I've written I have almost 0 control over > how it gets used so I have to be VERY defensive in my > coding practices. So maybe I took your jab a little > personally.
I admit it was a poor choice of words. I didn't intend to call anyone stupid. I separate actions from people and I'm aware that I do many things that I call stupid.
> >The Yorktown example, to me, is actually a good example > of > >how exceptions shine. In a system with proper top-level > >exception handling, this error would have come back to > the > >person doing data entry even if the GUI writers didn't > do > >their job and check for valid input. They might not > >understand the error but at least it wouldn't have > crashed > >the system. > > Yes, GUI writers should validate input. > > No, model writers should not assume that the data received > from the view is accurate. > > In fact, I'd go so far as to say that the model should > NEVER enter an inconsistent state without throwing an > exception that makes it clear that the client just did > something so bad it invalidated the model.
How is that different from what I am advocating?
> Think about this. How may classes do you have with > mutable hashcodes (meaning the hashcode changes when you > change certain properties)?
I don't know. I've done that once. I think it's a bad idea.
> Do you store these objects in > sets or use them as keys in part of your model? When an > operation is invoked that will change the hashcode, do you > update every HashSet that contains the object, and throw > an exception is one of those operations fails?
I'm not sure why there wouls be an exception but yes, the collections that held these Objects were observers on the Objects they contained.
> If a client tries to invoke a method with parameters that > will invalidate the model (meaning anything in the object > graph), and exception should be thrown.
I never said it shouldn't. What I said was that treating a null as equivalent to some other value is not making code better. If callers can't manage to meet the requirements of your method you are going to have a lot more trouble. This isn't to say that you should never check for nulls.
This discussion would be better if you had taken the time to understand the subtleties of the topic at hand.
> > I would argue that the NullPointerException is the "was > I > > stupid flag" and that if flight-control systems are > > passing bad parameters around then I don't want to fly. > > Then you probably do not want to fly (ignoring the fact > that airplanes probably do not use Java).
They probably do not have software either or at least not in the sense we usually think of.
> I would not want to fly in an airplane that cannot > tolerate faults.
Tolerating a fault and guessing when bad input is recieved are two very different things.
> In other words, you cannot build a reliable system if you > simply try to eliminate all of your bugs. Your application > must work in an acceptable way even though it has bugs.
There is no way to be sure that a system with bugs will work acceptably. It's like saying you can know things that are unknowable.
> In Java, you have to catch all exceptions at a point where > you can return to a defined state. > > For an airlpane, that would be no sensible strategy.
Why not? There's a pilot is there not? You think it's better for a malfunctioning system to fly the plane?
> You will probably want to have multiple programs that each > decide how to steer the airplane - let the majority decide.
This is what they do on the space shuttle but I doubt this is done for airplanes. The shuttle has four independently developed systems that vote. If the systems are not developed independently, there's no real point in having the redundancy. Also, a humam can pilot a plane, a human (likely) cannot land the space shuttle.
> For an airlpane, that would be no sensible strategy. > You will probably want to have multiple programs that each > decide how to steer the airplane - let the majority decide.
I did a little looking around and I found that this is indeed the basic approach but that it is also problematic. I still don't believe that it handles bugs in the software because the rundundant systems have the same bug. This technique is used for faults in the system or hardware.
My main point, going back to the Yortown example, is when you get a zero in a field where it makes no sense, what is the 'acceptable' behavior in that case if it is not to throw back an exception?
> > There are also several instances in code I work on > where > > null is a valid occurence and very different from an > > object, such as in your array example, that has no > > entries. In these cases we had to reduce overhead > (mostly > > free memory that containted nothing but lots of empty > > structures) and pick up some performance. I keep > hearing > > how arguments like these are red herrings and straw > men, > > yet when I implement these changes I get from 15 - 60% > > performance improvements. Projects like this are why I > > agree with your assertion in theory but not in > practice, > > as I also said. > > What about a singleton null object? Create a static > instance and refer to it every place you would have a > null? >
> > What about a singleton null object? Create a static > > instance and refer to it every place you would have a > > null? > > > > This one I'll file away. Thanks :-)
BTW: In Java we always have Collections.EMPTY_SET, EMPTY_MAP, EMPTY_LIST.
The issue of letting individual coders decide "I dont trust them" and check for null is how they handle it. I was on a project where one coder ignored nulls, one coder threw an exception and one coder logged it (and ignored it). Very confusing and dangerous. Especially when coder #1 edited #2s code and changed it.
> The issue of letting individual coders decide "I dont > trust them" and check for null is how they handle it. I > was on a project where one coder ignored nulls, one coder > threw an exception and one coder logged it (and ignored > it). Very confusing and dangerous. Especially when coder > #1 edited #2s code and changed it. > > It should be specified in the Contract.
I agree if you're talking about a social contract. Those developers should sit down and agree on a policy. I don't think anything else can be as effective.
> This is what they do on the space shuttle but I doubt this > is done for airplanes. The shuttle has four independently > developed systems that vote. If the systems are not > developed independently, there's no real point in having > the redundancy. Also, a humam can pilot a plane, a human > (likely) cannot land the space shuttle.
Actually in the case of the shuttle, all four software systems are identical. The purpose of the redundancy is not to deal with software bugs but with hardware failures of the computers and sensors.
This may seem odd now, but the computers were designed in the early 70's and actually use ferrite core memory.
> > This is what they do on the space shuttle but I doubt > this > > is done for airplanes. The shuttle has four > independently > > developed systems that vote. If the systems are not > > developed independently, there's no real point in > having > > the redundancy. Also, a humam can pilot a plane, a > human > > (likely) cannot land the space shuttle. > > Actually in the case of the shuttle, all four software > systems are identical. The purpose of the redundancy is > not to deal with software bugs but with hardware failures > of the computers and sensors.
Sorry, I was a little confused but there is a distinct software backup system:
"Since the ascent and entry phases of flight are so critical, four of the five GPCs are loaded with the same PASS software and perform all GN&C functions simultaneously and redundantly. As a safety measure, the fifth GPC contains a different set of software, programmed by a company different from the PASS developer, designed to take control of the vehicle if a generic error in the PASS software or other multiple errors should cause a loss of vehicle control. This software is called the backup flight system. In the less dynamic phases of on-orbit operations, the BFS is not required."
> > Then you probably do not want to fly (ignoring the fact > > that airplanes probably do not use Java). > > They probably do not have software either or at least not > in the sense we usually think of. It's real-time software and hardware. In real-time systems, Java is problematic, because it is hard to determine the longest possible time the garbage collector may take. For the same reason, hardware caches are problematic.
> > I would not want to fly in an airplane that cannot > > tolerate faults. > > Tolerating a fault and guessing when bad input is recieved > are two very different things. yes, of course. I wasn't implying you should not check for valid input.
> > In other words, you cannot build a reliable system if > you > > simply try to eliminate all of your bugs. Your > application > > must work in an acceptable way even though it has bugs. > > There is no way to be sure that a system with bugs will > work acceptably. It's like saying you can know things > that are unknowable. True. What I meant was that you need some sort of safety net . A monitor that can reboot your main application if it fails or a voter. If your safety net fails, however, you're still screwed.
> > In Java, you have to catch all exceptions at a point > where > > you can return to a defined state. > > > > For an airlpane, that would be no sensible strategy. > > Why not? There's a pilot is there not? You think it's > better for a malfunctioning system to fly the plane? Well, the pilot cannot steer an Airbus airplane (IIRC) without software, because they use fly-by-wire.
Not sure if anyone has already brought this up but I also agree that this is a great example of crap code.
I've seen code that is running supporting major businesses with such garbage.
Some of which ends up throwing
"NoSuchElementException"
only because an iterator is being checked for null, ignoring the fact that they should first check if the bloody thing actually has elements to iterate through.
Previous Topic
