PreviousNext…

Errors & exceptions

OK, so I know I'm a newbie at this object oriented thang, but I remember when I first learned about exceptions in Java, and how they work. As someone who was getting pretty tired of On Error Goto lblErrs…, it struck a chord let me tell you! Why clutter your code with error handlers and logic based on what error is thrown? The concept in Java, that exceptions are instances of / sub-classes of the core java.lang.Exception class makes real sense. De-couple your error handling from your code! Yes!

For me this works, I like it. I nodded all the way through Ned's article Exceptions vs. status returns even though I don't have the programming legacy he has (i.e. dealing with status returns in C or C++).

I was amazed therefore to see Joel Spolsky's article, Exceptions, in which he promotes the use of status returns in one's code, rather than exceptions. Indeed, he likens throwing and handling exceptions to the dark old days of "Goto". Which is kind of strong… ;-):

The reasoning is that I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's:
  1. They are invisible in the source code. Looking at a block of code, including functions which may or may not throw exceptions, there is no way to see which exceptions might be thrown and from where. This means that even careful code inspection doesn't reveal potential bugs.
  2. They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function. Every time you call a function that can raise an exception and don't catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn't think about.

With regards point one: yes, exception handling (not the exception itself) is indeed invisible to your code. That's the point innit? Now to point two: in Java, if I code something that could go wrong, my LS background tends to kick in I must admit. I find myself performing basic tests or asserts with regards an object or variable's state, before continuing with my code. My bad? Perhaps. But for stuff that can throw an exception, I wrap it in a try… catch block. Isn't that what they're there for? I am somewhat bemused.

Further reading:

Comments

  1. Exceptions can be used or misused. I tend to just use them to write my code, and not think about the "why". They're great if you need close a resource with the finally block.

    Here's a good discussion from Bruse Eckel at MindView, Inc.:
    http://www.mindview.net/Etc/Discussions/CheckedExceptionsNeill Laney#
  2. more on luke hutteman's blog as well:

    http://www.hutteman.com/weblog/2003/08/31-118.html

    we had a brief discussion on this when i was in j2ee training recently. the instructor pointed out that checked exceptions were one of java's big failures in practice, even though they were supposed to be one of the things that made java safer and better than other languages.

    the reason is that so many times developers just throw in an empty catch block just to get around the compiler. so you have this extra overhead in the code that does nothing, essentially, other than keep a record of the stack (which is where the overhead comes in) and we end up with lots and lots of code floating around with lazy/empty catch blocks.

    i guess its just one of those things that, like a lot of things with java, only becomes clear with a lot of experience. i'm still wrapping my head around all this for sure.

    great post ben, thanks a lot for putting this out here. i have some reading to do…

    :-)jonvon#
  3. Exactly: "in practice" things can be pretty crappy. But that's usually down to how the coder implements these things, which is why I find these discussions really useful: they often give one a heads-up as to the various issues to consider when designing and coding stuff.

    Which has got to make for better practice eh!Ben Poole#
  4. Man, This is the first of "The Best Domino Entry of The Week" awards. (Ok Now I own the name kids :oP)

    Congrats Ben!!

    jonvon: I think that you should post a lot more of that stuff buddy!!! We are enjoying :-D

    .::AleX::.
    Alex Hernandez#
  5. couldn't agree more ben!

    thanks alex! i'm just repeating stuff i've read or been exposed to lately and hoping i don't sound like a Compleate Arse! ;-) jonvon#
  6. 'course you don't sound like an arse!

    What I like about this kind of stuff is that we all get to explore and think about things we've possibly paid little attention to before — I know I have. Since I posted this entry, I've learned stacks more about exceptions, the issues people have with them, and why. So it's all good. We're in good company too. As Bruce Eckel says (discussing the concept of checked exceptions — good link jonvon):

    My theory is that when someone is trying to do something and you are constantly prodding them with annoyances, they will use the quickest device available to make those annoyances go away so they can get their thing done, perhaps assuming they'll go back and take out the device later. I discovered I had done this in the first edition of Thinking in Java:
    …
    } catch (SomeKindOfException e) {}
    
    And then more or less forgot it until the rewrite. How many people thought this was a good example and followed it? I began seeing the same kind of code, and realized people were stubbing out exceptions and then they were disappearing.

    See? ;-)

    Ben Poole#
  7. good stuff as always ben.

    i think poor mr eckel is taking too much credit for the laziness that is at the heart of every programmer. i'll be the first to admit that i've done this already, and even though i did try to read Thinking In Java, that web version was just too difficult to get through. so my bad error checking behavior is clearly my own fault (and not mr. eckel's). ;-)

    i'm still kinda thinking my way through this though… at this point i'm not completely sure that doing anything with the exception is always completely necessary. i mean, sometimes you write code that can only go one way and the exception really is just an annoyance.

    on the other hand there are some neat things you can do with them. i've beeen thinking about putting together a little articles database and posting a few ideas i've had along these lines. but lordy me, that would be yet another project that would end up being an excuse to not write creative writing type stuff. which is what i keep telling myself i should be doing with my offtime.

    i was hacking around so much (writing code) this past weekend my index finger was actually sore from hitting the touchpad.

    ack. i've got this geek thing real bad.jonvon#
  8. What really gets me is, if these A-list guys can't make up their minds, what hope is there for the rest of us? [smiley frown]

    But I agree with what you say, Ben. Joel Spolsky can think what he likes and in his environment perhaps he thinks it's better, but being a relatively recent convert to error handling that didn't include status checks, I'm sold. Exception handling for the kinds of apps us mere mortals write is just gnarly. It's gnarly on a simple, common-sense 'aaah, yes' kind of way. I think that's what really matters.

    While I find the Java approach a little restrictive compared to C++ and LS which don't force you to catch exceptions (or on errors), it still allows for cleaner code without status checks all over the show. Conversely, every method definition stipulates what gets thrown or not (unlike C++ or LS), so from that perspective Java is more self-documenting. (if you break the bad habit of just having a generic 'throws Exception' in each method signature, that is :-)Colin Pretorius#
  9. Agreed!!!

    Zeldman Rocks!!! But why the work at ALA is soooooo slow?

    I'm anxiuos for the 3.0 version

    http://www.alistapart.com

    .::AleX::.Alex Hernandez#
  10. I'm a big fan of exceptions, but there are a couple of issues that seem to come up quite often:

    Exceptions don't perform very well. You really need to make sure that exceptions happen only under exceptional circumstances. If it's going to happen fairly often, you're going to take a performance hit due to all that lovely stack unwinding. On a busy web server, this kind of thing can significantly impact scalability.

    Unhandled exceptions don't make good error messages for end users; neither do stack traces. A user likes to see "Situation A has occurred, you should now do X"; they don't want to see that an error occurred in some method on line 37, nor are they interested in what methods were called before that. An unhandled exception is bad form.

    Nik Shenoy#

Comments on this post are now closed.

About

I’m a software architect / developer / general IT wrangler specialising in web, mobile web and middleware using things like node.js, Java, C#, PHP, HTML5 and more.

Best described as a simpleton, but kindly. You can read more here.

";