Bruce Eckel is Wrong

I know Mr. Harold is much more experienced than me. It's pretty obvious he's more of an authority on most programming subjects. With that caveat I give my reasons why I despise checked exceptions in Java.<p>I've never seen code that got cleaner because of the use of checked exceptions. If you have a fairly complex piece of functionality that you've refactored mercilessly, it is quite possible to end up with a deep object hierarchy. If the checked exception is thrown at the bottom, that pollutes every interface on the way up the call chain to the method where the exception is handled. Also, whenever you are ready to catch the exception, you have to have a try/catch block and that aesthetically looks like an if-else statement, which means it is really easy to write it in an ugly way (merely having 3 lines of code for each the try and catch part is enough). All of this inevitably slows me down as I have to come up with a way to deal with those problems. It also frequently tempts me to just eat the checked exception rather than handle it.<p>I also think throwing a checked exception assumes too much about how I want to use that particular class/function. Suppose I'm using some sort of parsing tool to test complicated output (say, HTML). I'm only using this in tests. I do not want to have to handle exceptions. Even if it was in production code I may not actually care about addressing anything but the happy path.<p>I cannot effectively argue I'm not a newbie, writing buggy, shaky software. But I can't help but feel that the concerns of most programmers are more aligned with mine.

His argument that a library that accepts an interface without declaring all possible exceptions a method of that interface might throw is badly designed is misguided. This assumes that the writer of the library can know all possible custom exceptions that code written by the user might throw, which is impossible. But it is perfectly valid if the code that calls the library passes in an instance implementing the interface that might throw a CantFrobnicateException that the library doesn't know anything about if the calling code knows what to do if the library call fails with that exception.<p>The real design error here are still checked exceptions. What you really want are dynamic exceptions with an optional whole program analyzer that detects possible code paths that could lead to uncaught exceptions.

Elliotte Rusty Harold is wrong.<p>Checked exceptions are problematic because they version poorly, they implicitly presume the wrong model of exception <i>handling</i>, and more importantly, they prematurely decide the application's desired policy for error handling by encoding the "checkedness" in the type itself, where it is not available for configuration by the programmer.<p>The poor versioning is obvious. The OP says <i>"The superclass/interface was not designed properly for extension. Specifically it did not take into account the exceptions overriders/implementers might reasonably want to throw"</i> - and the only problem with that is the well-known difficulty in predicting the future.<p>But actually, it's more subtle: exceptions are usually a desired encapsulation violation. When programming to an abstract interface, you don't want to know the details of how it's implemented, but all the ways it can fail are a <i>function</i> of how it's implemented. You can't reasonably require the design of the most abstract levels of the system to predict every possible low-level implementation failure and state them out long-hand; the only reasonable implementation would be "throws Exception", which defeats the whole point of checked exceptions.<p>By presuming the wrong model of handling, I'm referring to the burden of creating a tunnel through the type system for your exception type between the point of the throw and the point of the catch. This burden is set up to optimize for catching sooner rather than later. But the thing is, usually you never want to catch; usually, the only exception catching you want done is at the highest levels of the system, in an event loop or request dispatcher. If you were expecting an exception you'd want to catch, the situation isn't exceptional; instead, you shouldn't be using an API that throws. .NET's pattern of e.g. Int32.Parse() vs Int32.TryParse() exemplifies this.<p>The OP tries to argue against this with the distinction between runtime errors and exceptions: <i>"checked exceptions do not require the programmer to provide handlers in situations where no meaningful action can be taken. When no meaningful action can be taken Java programs throw Errors"</i>. And this brings me to my third point. The determination for whether meaningful action can be taken <i>varies from program to program</i>, and is encoded in the very exception handlers themselves - i.e. it's the programmer who makes that choice, not the people who defined the relevant exception types.<p>His examples of error - <i>out of memory error, stack overflow, class not found, etc.</i> - actually make more sense as reasons to completely terminate the application, rather than make any attempt to catch. They're not really errors so much as panics.