3 ms·

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 exce

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.

scott_s 14y ago
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.
- ZitchDog 14y ago
  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.
  - scott_s 14y ago
    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.
    - ZitchDog 14y ago
      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?
evincarofautumn 14y ago
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.
- ZitchDog 14y ago
  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.
beersigns 14y ago
I agree with you but converting the masses, especially in the workplace, is tough.
- ZitchDog 14y ago
  Usually those architecture astronauts have a BaseException class... just make it extend RuntimeException and you're done!

scott_s 14y ago

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.

ZitchDog 14y ago
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.
- scott_s 14y ago
  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.
  - ZitchDog 14y ago
    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?

evincarofautumn 14y ago

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.

ZitchDog 14y ago
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.

beersigns 14y ago

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

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