3 ms·

What do you think of Java's declared exceptions (or whatever they're called)? They always seemed like a good idea to me, but were ruined by people being lazy or

What do you think of Java's declared exceptions (or whatever they're called)? They always seemed like a good idea to me, but were ruined by people being lazy or not understanding how to properly design exceptions.

shadowgovt 5y ago
Personal opinion: I think they were a good idea but in practice they don't work great because they try to pretend exceptions work differently from how they really work. They bump up against a reality of exceptions in a bad way: once you have a system for throwing exceptions, the set of types your code must handle becomes fundamentally unbounded because any of your dependencies can change at any time. If there are no exceptions and you have a function-call control flow, you can enforce that the only types the caller understands from the callee are the types in the signature. If your language supports thrown exceptions, then at the site of a function call, the value resulting from the call can be the values in the signature or any exception that can be generated by any function called by the callee (and in general, without control of the entire code stack, that set is unknowable). That's a fundamental truth of thrown exceptions, and trying to constrain it by putting the thrown type in the signature left us in the state we're in now... People just throw and catch very abstract exceptions because they'll have to handle those exceptions anyway, since it's impossible to guarantee a dependency won't try to throw them.
- pierrebai 5y ago
  > "If there are no exceptions and you have a function-call control flow, you can enforce that the only types the caller understands from the callee are the types in the signature." This has historically resulted in either ignoring errors from sub-functions, because their error return type don't map properly, or returning generic "i got an error" without any more information about what the error was. And all this was historically patched over by having verbose log files that could be written to from anywhere and the user had to peruse and try to make sense of after the fact. Some franework tried to create complicated error code (like Windows COM) but in the end there is no free lunch. Errors are hard.
earthboundkid 5y ago
With checked exceptions, if today my function can only throw a FileException, then tomorrow I cannot start throwing a URLException without breaking any callers depending on my function having only one possible exception type. The lead architect of C# cited this problem as one of his reasons for not adding checked exception to that language. https://www.artima.com/intv/handcuffs.html#part2 https://www.artima.com/intv/handcuffs.html#part2 The solution to the problem with to have errors be dynamically typed (a trait in Rust, an interface in Go, etc.) and insist that callers be ready for an unknown error type to bubble up.
cr212 5y ago
some disadvantages: i) There's RuntimeException which is an unchecked exception which could happen anywhere, so even the absence of a throws is not a guarantee of not throwing. ii) In order to avoid many different throws specifiers, you end up with wrapping exceptions to a smaller set of exceptions (e.g. JNDI may throw a NamingException that wraps an IOException) iii) IDEs offer to put try-catch { // todo } to avoid compiler errors. Developers often stop thinking then, where the right thing is more often to let it throw - e.g. I've seen FileNotFound being caught and logged (at debug) and not exposed to a caller, so a UI doesn't see it, with bad results.
- jcranmer 5y ago
  > iii) IDEs offer to put try-catch { // todo } to avoid compiler errors. This is the thing that always pissed me off. The default catch block should be to wrap it in a RuntimeException and rethrow it.

shadowgovt 5y ago

Personal opinion: I think they were a good idea but in practice they don't work great because they try to pretend exceptions work differently from how they really work. They bump up against a reality of exceptions in a bad way: once you have a system for throwing exceptions, the set of types your code must handle becomes fundamentally unbounded because any of your dependencies can change at any time. If there are no exceptions and you have a function-call control flow, you can enforce that the only types the caller understands from the callee are the types in the signature. If your language supports thrown exceptions, then at the site of a function call, the value resulting from the call can be the values in the signature or any exception that can be generated by any function called by the callee (and in general, without control of the entire code stack, that set is unknowable). That's a fundamental truth of thrown exceptions, and trying to constrain it by putting the thrown type in the signature left us in the state we're in now... People just throw and catch very abstract exceptions because they'll have to handle those exceptions anyway, since it's impossible to guarantee a dependency won't try to throw them.

pierrebai 5y ago
> "If there are no exceptions and you have a function-call control flow, you can enforce that the only types the caller understands from the callee are the types in the signature." This has historically resulted in either ignoring errors from sub-functions, because their error return type don't map properly, or returning generic "i got an error" without any more information about what the error was. And all this was historically patched over by having verbose log files that could be written to from anywhere and the user had to peruse and try to make sense of after the fact. Some franework tried to create complicated error code (like Windows COM) but in the end there is no free lunch. Errors are hard.

earthboundkid 5y ago

With checked exceptions, if today my function can only throw a FileException, then tomorrow I cannot start throwing a URLException without breaking any callers depending on my function having only one possible exception type. The lead architect of C# cited this problem as one of his reasons for not adding checked exception to that language. https://www.artima.com/intv/handcuffs.html#part2 https://www.artima.com/intv/handcuffs.html#part2 The solution to the problem with to have errors be dynamically typed (a trait in Rust, an interface in Go, etc.) and insist that callers be ready for an unknown error type to bubble up.

cr212 5y ago

some disadvantages: i) There's RuntimeException which is an unchecked exception which could happen anywhere, so even the absence of a throws is not a guarantee of not throwing. ii) In order to avoid many different throws specifiers, you end up with wrapping exceptions to a smaller set of exceptions (e.g. JNDI may throw a NamingException that wraps an IOException) iii) IDEs offer to put try-catch { // todo } to avoid compiler errors. Developers often stop thinking then, where the right thing is more often to let it throw - e.g. I've seen FileNotFound being caught and logged (at debug) and not exposed to a caller, so a UI doesn't see it, with bad results.

jcranmer 5y ago
> iii) IDEs offer to put try-catch { // todo } to avoid compiler errors. This is the thing that always pissed me off. The default catch block should be to wrap it in a RuntimeException and rethrow it.