Musings about Exceptions and Exceptions

Because I'm in the middle of documenting LightFrame (or what it is today), there's not much of interest to report from the programming side of things*. So, instead, I'll revisit a past musing, and how it got resuscitated with a twist.

*) Actually, there might be something I could write about the documenting process, and how I was forced to fork an open source project, to be useful for documenting. But that story has to wait...

Time for a trip to memory lane.

Almost a year ago, I confessed my confusion of the difference between PHP's exceptions and errors. In that article, I wondered why both of them exist, as they seem to do the same things, but concluded, that errors happened when there's nothing one can do to fix the situation, while exceptions give you a second chance to fix things, or at least fail gracefully.

When I re-read the article (I always love to read what I've written in the past, to see whether I've grown wiser or dumber since then), I noticed the little postscript that I left on the page: "One must wonder whether these musings bite me in the ass someday..." I was then worried that the article would give away my naïveness when it comes to error handling and/or programming. But, it turns out that the confusion between errors and exceptions is nothing compared to the confusion between exceptions and exceptions.

Java, the promised language of correctness, robustness, design patterns and exceptions, brings uncertainty of how to really use its exceptions. Let me present you: Exhibit A. Turns out that I'm not the only one wondering about the semantics of stuff.

Java has two kinds of exceptions, runtime exceptions and checked exceptions. Runtime exceptions may be thrown at any place of the code, and they can be caught, or disregarded, while checked exceptions must be caught and dealt with – If you don't catch a checked exception, the code won't compile. The question was when to prefer one over the other.

I gave my opinion on the matter: I argued that the case in question shouldn't use exceptions at all, but a return code to differ between a successful run and a failed run – a third, totally different, point of view. Funnily enough, this answer was the publicly most accepted answer at the time of writing this!

What a relief: I'm not the only confused one!

...or actually, that's not a good thing at all. I would rather have it clear-cut how to use what features. It would make everyone's lives easier, when there's an intuitive and clear separation between Method A and Method B – that there would be no question of which method to use where, because doing it The Other Way would be just stupid, dumb and ass-backwards.

Unfortunately. This isn't going to happen. There will always be nuance-differences between Method A and Method B. They came to be when a language developer encountered a situation which couldn't be dealt with in the precise manner that would be 'correct' for that particular case. So that particular case gets generalized, and it's a free-for-all for anyone to use in what ever context they wish. This is why you can do the same stuff in a zillion different ways, each just a tad different from the next one.