> Bill Venners: But aren't you breaking their code in that case anyway, even in a language without checked exceptions? If the new version of foo is going to throw a new exception that clients should think about handling, isn't their code broken just by the fact that they didn't expect that exception when they wrote the code?

> Anders Hejlsberg: No, because in a lot of cases, people don't care. They're not going to handle any of these exceptions. There's a bottom level exception handler around their message loop. That handler is just going to bring up a dialog that says what went wrong and continue. The programmers protect their code by writing try finally's everywhere, so they'll back out correctly if an exception occurs, but they're not actually interested in handling the exceptions.

> The throws clause, at least the way it's implemented in Java, doesn't necessarily force you to handle the exceptions, but if you don't handle them, it forces you to acknowledge precisely which exceptions might pass through. It requires you to either catch declared exceptions or put them in your own throws clause. To work around this requirement, people do ridiculous things. For example, they decorate every method with, "throws Exception." That just completely defeats the feature, and you just made the programmer write more gobbledy gunk. That doesn't help anybody.

1) Precise exception specifications leak implementation details. This will bite you badly, e.g., when you want to change the implementation from under a published API.

2) The times when we only care that some exception occurred vastly outnumber the times when we care about the exact types of exceptions that may occur. Checked exceptions don't add any value to the common case, in fact they make it worse, because generic exception handlers tend to live many levels up the call stack from where exceptions are thrown(1), and therefore they "aggregate" large amounts of code that that can collectively throw a huge range of exceptions. If you were to carry around detailed "throws" clauses, they would be a mile long.

The funny thing is, all solutions that solve the problems created by checked exceptions do so by subverting the mechanism one way or another. So you're better off without checked exceptions in the first place.

I've always been interested in this discussion because it's one of those cases where an idea seems very good on paper, only to turn out quite bad in practice.

(1) This observation is what makes exceptions such a useful mechanism in the first place.

At the very least it'd be useful for when I'm wearing my "DLL author" hat, since it'd give me an easy way to look through the public interface and make sure exceptions won't be causing unrighteous leakage of implementation details for the end-user. I'd rather not put users in a situation where they have to look at the framework source in order to interpret an exception. It's kind of irritating when that happens.

I think it's really not something that should require special language statements, though. A static analyzer should be able to automatically figure it out.

"To work around [the need to declare what you intend to do with each exception] people do ridiculous things. For example, they decorate every method with, "throws Exception." That just completely defeats the feature, and you just made the programmer write more gobbledy gunk. That doesn't help anybody."

Ok, so what you did instead was to effectively put "throws Exception" on every method by default. You actually implemented the workaround you've just criticised into the language?

And what's the effect of this - whenever you call a method in an API, you have no idea what could go wrong with it, so you can't write code to handle it. It wouldn't be so bad if a method's potential exceptions were documented, but they never are. So you end up in a situation where you just code for the simple "happy case", run it, see what breaks, put some exception handling in (for just Exception) where you can, run it again, etc. It's a dreadful way to write code.

I'm not saying Java's checked exceptions were great - far from it - but C#'s "solution" is terrible. The number of times you end up with a NullException because some method failed somewhere deep in your code and something else didn't get initialised is unreal. If you don't believe me, try working with Sharepoint for a few minutes, and that's Microsoft code.

[edit - spelling]

C# is basically silent on the checked exceptions issue. Once a better solution is known—and trust me we continue to think about it—we can go back and actually put something in place. I'm a strong believer that if you don't have anything right to say, or anything that moves the art forward, then you'd better just be completely silent and neutral, as opposed to trying to lay out a framework.

...

I'm a strong believer in being minimalistic. Unless you actually are going to solve the general problem, don't try and put in place a framework for solving a specific one, because you don't know what that framework should look like.

That implicit throws clause was already there in any language that contains unchecked exceptions for things like dereferencing a null pointer, or assertions, etc. So, no, that's not what removing checked exceptions does. Personally, I'm a big fan of Guava's Throwables class. The java I write these days transmutes all checked exceptions into unchecked wrappers at any API boundary that tries to force them on me. And, no, this doesn't mean I'm only coding for the happy case. Rather, I'm choosing where and how to handle the sadness.

Regarding null exceptions, they are runtime exceptions in Java so it's much the same there. It would be very annoying if they were checked exceptions.

The idea with checked exceptions are that they should be used for errors which the caller should be forced to handle. But this property is entirely dependent on the context the function is being called from! For example, if the user is specifying a filename for a file, I should be expected to catch the error and display feedback to the user. However, if I just wrote the file to disk 5 seconds ago, I shouldn't be forced to trap the error!

The crux of the problem is this: the severity and recoverability of an error is known only by the caller of the function, not the function itself. Checked exceptions attempt to foist this information into the function itself, where it is unknowable and generally inaccurate. Checked exceptions are a misfeature if I ever saw one.

The crux of the problem is this: the severity and recoverability of an error is known only by the caller of the function, not the function itself.

I agree with that statement, but not that it is the crux of the problem with checked exceptions. That statement is an argument for general error reporting - it need not even be exceptions. Simply, the function that encountered the error does not know what to do about it, so it must report it on up the stack. We could just as easily accomplish that with error return values - I'm not saying we should, just that I think your argument is too generic to support your conclusion.

Checked exceptions attempt to foist this information into the function itself, where it is unknowable and generally inaccurate.

And that I actually disagree with. Checked exceptions require that the calling function acknowledge that an error has occurred, it does not require the calling function to handle the error. The calling function could easily catch the exception and rethrow it, or just add the exception to its own throws clause.

The C# designers' argument is that what I described is generally what people want to do, so why not just make it the default? That default is unchecked exceptions.

But why do they require the client to acknowledge the error? Better stated, why would one use a checked exception versus an unchecked? The general wisdom (and perhaps this is where I'm mistaken) is that checked exceptions generally indicate a more recoverable error. This is why checkedness doesn't belong in the function itself: it's an indication to the caller of the error's recoverability, which is completely unknowable.

With that said, I think it may be reasonable to say "You may be able to recover from a missing file, but no one can help you if this pointer is null." It's the difference between a logic error in the program (null pointer exception, array out of bounds exception) and configuration errors (missing file, lost connection). Checked exceptions are typically explicitly thrown by the called function; unchecked exceptions are typically encountered because the called function itself had an error. In other words, checked exceptions are when the called function recognizes an error, and throws it up to its caller.

So, I am able to distinguish them myself. But I'd still rather not have checked exceptions. The mentality of "acknowledge all errors" makes more sense in the error-code model, as seen in C programs. In that case, if you don't at least check for and report all possible errors that can arise from calling a function, then they will never get reported, and your program will silently be wrong.

Right, I understand that. And I was merely pointing out a flaw in your argument against my argument.

You may be able to recover from a missing file, no one can help you if this pointer is null

My argument (which you seem to be doing a great job of ignoring) is that this distinction is completely unreasonable. As the calling function, I am passing in the pointer, therefore I am the only one who can know whether the null pointer is a recoverable issue! Consider the ArrayOutOfBoundsException - perhaps the array bounds are passed in from the user interface, and the error should be trapped and reported to the user. This checked / unchecked distinction is simply nonsensical from the called function's point of view.

Checked exceptions are typically explicitly thrown by the called function; unchecked exceptions are typically encountered because the called function itself had an error

This is not typical, is not how you are using them in your examples, and also makes no sense. What is the difference between encountering a particular error within a function or a sub function? What if the logic in the function is later extracted into a subfunction?

The function may encounter an error but it is not the caller's fault - that's what I mean by "the called function itself has an error."

Of course I'm using hyperbole to point out the absurdity of making this distinction, which on the surface may seem reasonable. The fact is, however, the fewer assumptions a function makes about it's calling context, the better. The whole point of functions is that they are to be reused in ways the author may not have intended. The checkedness of an exception is an assumption about the calling context of a function which should not exist.

Checked exceptions are not about imposing responsibility, but about disclaiming it and deferring it to a higher authority in a type-safe manner. And the issue seems to be more syntactic than philosophical; Haskell models checked and unchecked exceptions as a monad (or as a monad transformer for running exceptional code in another monad) and it feels very natural.

The difference is that we can require them to be dealt with by the caller, which is generally thought to be an indicator of the recoverability of the error (I should not have said severity, sorry) which does not belong in the function as it makes no sense in the context of a function.

Checked exceptions are a nuisance (I'm actually glad Scala doesn't enforce them vs Java), but often leads to inexperienced C# devs writing very fragile apps.

With C# you have to examine docs and source to identify exceptions which could be thrown. Many programmers don't bother, leading to things breaking. In Java the compiler forces you to think about it. I'm not in favour of checked exceptions, but the arguments against them tend to be a bit simplistic.

Which is generally what you want to have happen. Failing fast is a good thing. If your code does anything other than "stop executing" after encountering an exceptional situation, it should be very something carefully considered and well-thought-out. With checked exceptions, the "I'm in a hurry to get this working" version of the code often ends up looking a lot like:

  try {...}
  catch(ExceptionType ex){ //TODO figure out what to do here }
  ... keep going ...

So I think the C# design choice leads to the least pain under bad conditions. I'd rather have a fragile application than one just robust enough to write bad data to my database.

That said, it's not perfect. Any sufficiently lazy/stupid programmer can write the equivalent of "On Error Resume Next" in any language.

Still better than:

    try {
        // Do broken stuff
    } catch (Exception e) {
        throw new RuntimeException(e); // TODO: Add a domain-specific runtime exception so we can actually catch this
    }

[0]: Actually, that's not fair. Most people don't bother to include the TODO.

Throwable will catch Errors as well as Exceptions, such as when a constructor called from a dependency injection framework fails. It's kind of irked me for a while that I had to know that. I would have rather had "catch" work on anything, with the option to check the class and rethrow once in a great while. That is, in the few places where the error checking/logging actually belongs (as stated in the article, with which I obviously agree).

There is indeed great irony in Java code littered with catches, which then falls out and kills the main loop without logging anything. (I recently had to diagnose such a case in a system at work over the phone -- sure enough, that's exactly what was coded)

That way you (through the IDE) could know at any point of your code what exceptions could happen (and not have to guess or go through all the called code to identify them).

One Java module I had the misfortune of writing theoretically had to deal with checked exceptions on the majority of its calls, and the only possible response to virtually all of them was to crash, because in that context, it could only have meant someone had either ripped the DRAM off the board, or placed the board in a particle accelerator.

And there was nothing particularly special about the module aside from the extreme concentration. Every piece of Java I've ever written or even looked at has this same problem on a reduced scale.

My point is to show how utterly broken and worthless the concept is. Either there's a ton of exception-"handling" boilerplate that does nothing useful, or there's "throws Exception" everywhere, itself useless boilerplate that exists only to tell the compiler to buzz off.

throw new RuntimeException(exception);

Edit: If there weren't exceptions for every mundane thing I think I would prefer no checked exceptions also.

What he completely ignores is the possibility to wrap exceptions to either aggregate them or to convert them into unchecked exceptions.

Whether you convert the throws clause to a common supertype (which very soon converges to the base type Exception), or wrap everything in a RuntimeException, you are effectively emulating a language without checked exceptions. So what was the point in the first place?

Perhaps.

In my projects, I use wrapped exceptions to convert "what blew up" exceptions into "what to do about it" exceptions. A poor man's event routing. For example, I wrote an ETL workflow thingie that would retry, reset, restart, backoff (throttle) depending on what was failing.

I'd be totally game for pre declaring what exceptions your code will catch, harkening back to the days of "on message do this" type programming. Then the compiler can tell verify that all the thrown exceptions get caught by somebody.

Meanwhile, I've never had a problem with checked exceptions.

Methinks the real cause of angst over checked exceptions are all these mindless frameworks, APIs, libraries, strategies, design patterns, aspects, inversion of common sense, injection of nonsense, etc.

The complexity borne of the manner in which Spring, JPA, Hibernate, connection pooling, aspects, MVC, blah blah blah attempt to hide, obfuscate, decouple, mystify, pseudo architect "solutions" ... well, it's just insane.

Someone upthread off-handedly noted the irony of declaring all these exceptions only to have the main event loop eat an exception without any logging. Story of my life. Debugging silent death failures really, really sucks.

Which is why I work as "close to the metal" as possible and worry not about unchecked exceptions.

The problem is, that they are not composable and most languages have no syntactic sugar for dealing with them as Monads.

Other checked error mechanisms like Either or are much easier to manage.

I do hope e.g. Java sometimes in the future gets syntactic sugar to deal with checked exceptions as Monads.

Android is full of brand new checked exceptions.

And I do what I always do with checked exceptions:

    catch (e) {
      throw new RuntimeExeception(e);
    }

  void function()
  {
  try:
    function_body...
  catch(Exception e):
  finally:
  }

  void function()
  {
    try
    {
      function_body...
    }
    catch(Exception e)
    {
    }
    finally
    {
    }
  }

I do agree that having try/catch at method level would be useful in many ways - as an additional piece of syntax.

That is really limiting in some scenarios.

Case in point from a popular framework, Django: the standard way of getting an object from the DB via the ORM is Class.objects.get. This method either returns a single object or raises on exception if there are zero rows in the db or another exception if there are two or more rows. It may also raise other kinds of exceptions.

Now, it's clear that having zero rows is not very exceptional, and even >1 is somewhat debatable. Note especially that this is not just some weekend project by a nobody, it is a framework that is widely used and respected.

I can't agree about Class.objects.get - method must return exactly one row by known pk value.

So it perfectly sane to raise exception for zero rows.

Class.objects.filter is working the way you want.

I have every reason to believe that the Django devs are capable people who thought about this and landed on this specific usage with a clear rationale... but it still is a misuse of error handling capabilities of a language. And a sort of misuse that everyone else does sometimes as well.

It's seemingly nearly mandatory in discussions regarding exceptions to bring up Common Lisps's condition system, which is a superset of exceptions. I've included a link to a chapter from a book on Lisp.

http://www.gigamonkeys.com/book/beyond-exception-handling-co...

    func MaybeAnInt() (int, error) {
        if FAIL {
            return 0, errors.New("this is the error message")
        }
        return 42, nil
    }

    x, err := MaybeAnInt()
    if err != nil {
        // handle your error
    }
    // normal shit here.

You now have to mix up your exception code and your normal code (or, as I suspect most people will do, ignore the error return value).

Did they kill stack traces too?

If you would think a bit more broadly, you might also see this so that all the error handling code is visible, explicit and right there with the actual logic, and not hidden away what might be (and often is) multiple layers of modules.

that's not true. You can ignore the second parameter by explicitly naming it with an underscore, like this:

    x, _ := MightFail()

>Did they kill stack traces too?

no, we have stack traces.

Also, it's Go, not GO.