Hacker News Reader

Comment by ZitchDog | Hacker News Reader

I have thought quite a bit about checked vs unchecked exceptions and come to the realization that there is a fundamental philosophical problem that checked exceptions can never overcome.

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.

View on HN

I agree with the C# designers' reason that checked exceptions are not a good idea, but I don't agree with yours. In other words, your argument is different than theirs, and I don't agree with it. (Although I still agree with your conclusion.)

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.

Checked exceptions require that the calling function acknowledge that an error has occurred

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.

Note that I was not arguing for checked exceptions. Rather, I was arguing that your argument does not support your conclusion.

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.

Note that I was not arguing for checked exceptions.

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?

I'm sorry if you feel that I'm ignoring your distinction. I'm not trying to ignore it, but argue that I think we can distinguish between "likely recoverable" and "likely not recoverable" for most cases. Nothing prevents you from catching unchecked exceptions. So if you know that you're passing in a may-be-null-pointer-and-it's-okay, then you can do an unusual thing and catch that exception. I agree that we can't classify all exceptions as recoverable or not recoverable from inside the called function, with full accuracy. But I disagree that we can't make reasonable guesses that will be true in most cases.

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."

Sure, we could guess at all sorts of things from within a function. We could guess that the function is running from a terminal, and simply print the result of the function to stout. Hell, we could guess what the caller is going to do with the result of our function and just do that instead! Why even have a caller at that point?

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.

I don’t see how checked exceptions impose decisions of severity & recoverability on a function. If you are a function, exceptions are how you notify your caller that something has happened for which you are not responsible.

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.

All exceptions (checked or otherwise) disclaim and defer the error in a type safe way (unchecked exceptions can be declared in the throws clause too!)

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.

I agree with you but converting the masses, especially in the workplace, is tough.

Usually those architecture astronauts have a BaseException class... just make it extend RuntimeException and you're done!

Reply on news.ycombinator.com