Errors & exceptions 14 Oct, 2003
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:
- 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.
- 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:
Here's a good discussion from Bruse Eckel at MindView, Inc.:
http://www.mindview.net/Etc/Discussions/CheckedExceptionsNeill Laney#
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#
Which has got to make for better practice eh!Ben Poole#
Congrats Ben!!
jonvon: I think that you should post a lot more of that stuff buddy!!! We are enjoying :-D
.::AleX::.
Alex Hernandez#
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#
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):
See? ;-)
Ben Poole#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#
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#
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#
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#