A trend away from checking for null objects?

[Schmide]

I'm currently going through an Android 2 book* and the code has thrown many exceptions for using null objects. Some of these are from expecting certain resources are available (i.e. GPS location) others are from using a database that failed to create because of a bad SQL statement.

I've always strictly checked any queried object's value before use. It seems the trend has been to forgo this to make more simple readable code and the expectation is for certain interfaces to always return.

I know a lot of what is written in a book is just for example sake. How do you guys feel about forgoing checking for simplicity and guaranteed results from queries?

*Professional Android 2 Application Development by Reto Meier

 

[Train]

Trending? From one book?

I've always heard the phrase "exceptions should be exceptional" as the majority feeling on the subject.

 

[Schmide]

This really is only partially about exceptions. Certainly you could throw an exception for receiving a null interface, but you could also avoid some processing and continue without getting that extreme. What I'm saying is the best error checking is made before the error is made.

I'm mostly just ranting over buggy code.

 

[DaveSimmons]

I've read an article or two pushing universal exception handling as being somehow more uniform than writing function-specific error checking and correction but I'm old so I disagree with such newfangled postmodern notions.

(That is, putting all of your failure and unexpected value code into whatever the catch() block is for your language)

And you can pry the assert()s out of my cold head hands 🙂

 

[Ken g6]

As I recall, when I used PMD a few years back, it threw out warnings when there were more than something like 5 if's in a block of code. In this way, it seemed to encourage try/catch over if/then/else.

I tend to disagree with it; I do use try/catch, but only for cases that really are exceptional.

 

[Markbnj]

There are no rules that apply in every situation, but I have some guidelines I follow, all premised on the main idea that catch blocks are where your code handles exceptions, and exceptions are for... exceptional conditions, i.e. not expected to occur in the normal flow of execution of the program.

So the question in this case seems to be: can the thing you're asking for legitimately be null in the normal course of execution? If yes, then you already know you have to test for it and branch based on what you get back. An example is a setting that hasn't been created yet, and so will take a default value if it is found to be null. Or a handle to a file that might not be there.

If the answer is no, the thing should never be null under normal circumstances, then you don't need to test for it. An example would be a handle to some system object. But in those cases you still need to consider the what-ifs. If the thing does, by some chance, come back null, you're going to reference it somewhere, and at that point its going to throw an exception. How far up the stack is that exception going to go? Where do you need to catch it and what do you need to do in order to be sure that even when the unthinkable happens the program deals with it as gracefully as possible?

My philosophy has always been: the user never sees a system error. They may see a dialog from me, and all it may say is "holy crap system error," but the presence of that dialog means I knew it might happen, and I did something about it 🙂.

 

[degibson]

I would suggest that coders in avoid general rules like "don't check for NULL -- treat it as an exception instead" or "always check for NULL".

Instead, handle exceptional cases at the logical place to handle them. It's much better to retry a few times than print "cannot connect to network" on the first failure. Faults need to propagate up until they can be handled and/or converted to reported errors.

 

[tfinch2]

Faults need to propagate up until they can be handled and/or converted to reported errors.

This, ugh.

 

[Monster_Munch]

If you're getting SQL errors surely that means you have a bug to fix somewhere.

I used the same book to learn android development and I haven't had to put in any extra checks on my queries.