Objection Mr Santos, leading the witness

I’m going to confess up front that I like checked exceptions, and I feel that the lack of checked exceptions in C# condemns the language to something that is a toy, a sham and something that should never be trusted to be used in enterprise development.

Now, some of my colleagues and friends may not agree with me, but I don’t care. This is one windmill that I’m prepared to tilt at, and keep tilting at until people get the point. Unchecked exceptions are ok if you don’t mind having to read all the code to work out what is going to happen when you miss catching something and then have it fail in a place miles away from the actual error. Checked exceptions done properly (remember, done properly) are an absolute bonus to layering, failure management and robustness. They don’t “spiral out of control” as many critics say. If you have 100’s of checked exceptions in your tiny program, then you’re doing it wrong. Having a “try/catch” block is good programming practice, and not “too much typing” as critics argue. If you can’t be bothered writing code properly, then sod off and write some crappy VB that people expect to crash. Leave me to write Java code that works properly. Don’t sully the name of the Java industry with your shitty code.

Now, back to the title. In this weblog titled, Things that could be different – Part 1: Exceptions Mr Santos waffles on about something being wrong with the Exception mechanism and tries to make the point that this block of code:

try {
...
} catch (Exception e) {
//do something and...
throw new BusinessException(e);
}

Would be better handled if we had new classification of Exception called CheckedException and UncheckedException so that it wasn’t hard to separate the two. Ahem, “Objection Mr Santos, you’re leading the witness.”

Frankly, this particular load of bollocks is only setup by doing something mind-numbingly stupid. Any developer who has the catch (Exception e) code and thinks that it’s OK should be taken out and burnt. Simple as that. Some may say my stance is too strong, but frankly, we need to be rid of those people before they can teach anybody else these sorts of things.

To people who persist in writing code that looks like this I offer this advice; do yourself a favour, and learn to program properly. That would make everybodies life easier and we wouldn’t have people wanting to change the Java syntax as their new favourite indoor sport.

Advertisements

10 thoughts on “Objection Mr Santos, leading the witness

  1. respectfully, I disagree. When you are writing generic code (and I mean *really* generic code), then you may well wish to catch any possible exception that that code can generate (if, for example, it’s a plugin), and then produce a useful error message to a UI or somesuch.
    If it’s your OWN code, then yes, you shouldn’t be catching Exception, but for plugins I think it’s good practise. Somebody else’s plugin should not take down your code because it throws a RuntimeException.

  2. You don’t have to be respectful, that’s ok. 😉 I never am. And most people don’t with me.
    I’ve never thought of that situation, where somebody has foisted busted ass code onto me. In that situation I’d probably do a couple of things.
    Firstly, find them and burn them. Secondly, do everything in my power to remove the busted code from my system.
    Maybe from a completely defensive mechanism you might want to do this, but interestingly this was also proposed during MIDP 2.0 specification (wrapping the entire MIDlet in a “catch Exception”) which I also argued very strongly against.
    Thanks for your input Andrew.

  3. Hi Jon,
    First of all, I don’t think you’ve read my blog properly. Note my own comment about this code:
    If you need to write code like above – ok, it is a polemical issue, but sometimes it is indeed needed –
    So, as I said, sometimes it is neeeded. Do you want an example? I’ll give you one.
    Let’s suppose you are writing a SQL Driver implementation. What do you want to do with any Exception that is thrown by your internal code? Don’t you wanna wrap it inside a SQLException? OK, maybe you don’t want to do that with RuntimeExceptions because probably, after some testing, you reach the conclusion they only can happen if the user do wrong things with the API. Would it be wrong if, inside your code, you wrote a block that had catch(Exception) and then wrapped it inside a SQLException and rethrew it? I don’t think so. That is an example of what I was talking about.
    Prevayler – http://www.prevayler.org/ – , a terrific idea for object prevalence, also contains similar code, but they catch RuntimeException before catching Exception for obvious reasons. It is a necessary thing in some situations, although the vast majority of uses of this block just happens because people cannot understand good exception handling or are just too lazy.
    Notice I never told anyone this kind of code is the way you should handle exceptions all the time.
    Thanks for reading my blog 😉

  4. Thanks for the response Michael. I still don’t agree. I can’t think of a situation where I would want to “catch Exception” even to catch all the RuntimeExceptions.
    I just did a quick look, and in JDK 1.4.2 there are 48 classes that extend RuntimeException and a further 41 classes that extend various categories of those. (Don’t shoot me if there are more, I just did a quick “Open Type in Hierarchy” with the current project I have open in Eclipse and counted the classes).
    I can’t forsee that I would ever want to work with a situation, and I don’t ever want to work with people that think it’s a good idea to treat all of those as “the same error”.
    This next bit is why it’s important to me. Exceptions are part of the contract that you have with the calling code. If that contact changes (like the addition of an extra exception) the current contract is invalid, and you may want to do something different with the new exception. I don’t want my code just to swallow the new “GoshThatWasNotGreat” exception and hand it off to the UI to just barf, I want to sit and think about what I should do.
    That’s why I like Checked Exceptions, if the contract changes, my code will no longer work.
    You are right, this is an area that invites great controversy, but as I said in my original blog entry this is an area that I take as a crusade, and I feel that application specific RuntimeExceptions are (generally) a bad idea, and that “catch Exception” is nearly always a bad idea.
    And certainly, I don’t think that using it to wrap “anything that just happened” is a good idea. At the stage when I was writing your example, I’d be catching the specific categories of exception (IllegalArgumentException is different to me to BufferOverflowException, two runtimes that are likely in your scenario) and treating them as appropriate.
    I will notice that you didn’t say handle exceptions like this all the time, but you do use it as an example for why you should change the state of Java, and I’m saying that you should change your exception catching strategy.
    Thanks for responding to my ramblings.

  5. You mention having to “work out what is going to happen when you miss catching something and then have it fail in a place miles away from the actual error.” Actually, if you inadverdently fail to catch an exception, the stack trace will usually point you pretty close to the source of the error. Catching exceptions prematurely actually leads to the problem you describe more than failing to catch them at all. It’s a common misperception (implanted in developers’ minds by the compiler’s handling of checked Exceptions) that in Java, the best thing to do is catch an exception as early as possible, and that the worst possible thing from a debugging stand point is an uncaught exception. Reality and experience, however, show that the opposite is true.
    Please see an article I wrote for java.net, Three Rules for Effective Exception Handling. Pay particular attention to the section titled “catch late.” Also, see my Exception Horror Stories for more examples of inappropriate exception handling. Most of these result from developers eagerness to catch checked exceptions early.
    Three Rules for Effective Exception Handling:
    http://today.java.net/pub/a/today/2003/12/04/exceptions.html
    Exception Horror Stories:
    http://homepage.mac.com/jimothy/articles/exceptions/horrorStories.html

  6. Hi Jon,
    I am not going to be picky about your count – I haven’t even taken a look at javadoc to see if you are right. However, I am afraid I cannot explain things better if you don’t use the examples I gave you – about a SQL Driver and/or Prevayler – to prove your point. I find them to be good arguments and you simply didn’t mention them.
    I also think things might get clearer if you read my replies to comments other people have made in my blog.
    Please let me know when (if) you comment about the examples I gave or about my replies either by dropping me an email or by posting a reply to my original blog entry.
    Thanks,
    Michael

  7. Jon, you seem to argue that having a CheckedException hierarchy would be bad.
    There’s one place I’d love to be able to catch them,
    Class.forName(someVariable).newInstance();
    can throw so many checked Exceptions that it’s very annoying so catch them, since the bevaour for each case is the same “The plugin you supplied cannot be loaded: ” + e.getMessage().
    Having to do
    catch( ClassNotFoundException e )
    {
    handleException(e);
    }
    catch( IllegalAccessException e )
    {
    handleException(e);
    }

    is damn annoying.

  8. Hi Tim,
    What the hell are you and Phil doing ? Don’t you have a project to get done ?
    No, I’m not arguing over a checked exception hierarchy, and in many cases (exactly as you describe) I think Sun got it wrong when they developed their contracts. In fact, I think a proper checked exception hierarchy is super good, and then provided what you want to do is the same (as in your example) it shows the intent properly.
    Doing a “catch ClassFindingAndLoadingException” is far more preferable to the structure that currently exists, but in my view that’s a long, long way (another country, or even planet) from “catch Exception” which I think is evil and wrong.
    To recap on what I really feel.
    1. People do dumb things with exceptions.
    2. The example given by Michael I thought was dumb and contrived to make a point about why we should change exception, hence the title on the blog posting.
    3. I would rather see people do the “right thing ” (and that includes Sun) with exceptions rather than change the way that exceptions work.
    Now of course, my blog is just a place for my own uninformed opinions and to generally poke at things I feel like. People surely shouldn’t expect a coherent thesis. Or should they ? Maybe I’ll try and be less flippant and include greater clarity in later postings, but that probably wouldn’t be as much fun
    .

  9. One thing I would note from the plugin approach is that, if something dies, it can die from an ERROR that is thrown (I think assertions are errors). I don’t actually wrap my code in literal catch(Exceptions) (well, generally), I instead mostly rely on ThreadGroup.uncaughtException() and putting things in their own threadgroup. This has the neat side effect of making sure that any ‘sub’ thread will (unless the user does his own work) give me their exception, instead of failing in a weird way.
    Something like an IndexOutOfBoundsException or NullPointerException or ArrayStoreException are things that should be wrapped up in a checked exception in my view, as generally, they are solely implementation details. Maybe you should do them individually for every time of exception, but I think very very few people do.

  10. You’re an idiot. Checked exceptions are a horror and a misguided attempt to regulate something that cannot be regulated. And the only way to keep it workable is either to use throws Exception everywhere (which is the RIGHT way) or to catch exception types at places where a given type cannot be thrown and bloody wrap it in another exception or -even worse but more common- just forget about it. Wrapping Exceptions make you loose the original event and forces one to walk the entire bloody stack of catches to see what moron decided to call an A exception a B exception. This also fscks up the stacktrace, obliterating another way to find the trouble.
    I don’t know why people WANT to catch exceptions – you should catch ‘m only when you KNOW what to do with them. And if you code right that’s surprisingly little. And catching them just to throw another one is daft.
    I’m currently writing a JSP tag library and the godforsaken idiot that created the interfaces there only want JspExceptions. This means that ALL OF MY CODE that throws other stuff needs to be wrapped in a handler WHICH DOES NOT DO A FRIGGING THING BUT WRAP THE BLOODY EXCEPTION! What a waste of time and a loss of meaning!
    Man, people are stupid.

Comments are closed.