4 ms·

This is one of the problems with checked exceptions. The library author is in no position to expect me to handle an exception. Whether or not I can relies on th

This is one of the problems with checked exceptions. The library author is in no position to expect me to handle an exception. Whether or not I can relies on the design of my system, which they have no window into.

stickfigure 4y ago
And 99.9% of the time the client is just going to catch generic Exception and doesn't care what the type is. Rollback a transaction, return 500 or display an error dialog. Done. It doesn't matter what the client library thinks.
rowls66 4y ago
That is true, so the library should throw the checked exception, and if the caller has no way to handle it, it should wrap the checked exception in an unchecked exception and throw the unchecked exception. Not too hard, and library clients that can handle some checked exceptions will be able to. I hate libraries that only throw unchecked exceptions. It seems easier initially, but makes writing correct code more difficult.
- Quekid5 4y ago
  > If the caller has no way to handle it, it should wrap the checked exception in an unchecked exception and throw the unchecked exception. Not you have a new problem: How is the code calling the caller supposed to know about that exception? You can't even catch it (even if you know about it!) using normal try-catch because what you have to do is catch the wrapper exception and then check inside that for the exception type you expect via instanceof. Checked exceptions (at least as implemented in Java) are horrible for the composability of code wrt. error handling. That is why most libraries eschew checked exceptions these days. Unfortunately, large bits of the standard library in Java forces their hand wrt. re-wrapping stuff like InterruptedException and IOException and the like. (Not to mention, most of the time you really shouldn't be catching exceptions in very small scopes or at the very highest level in your code. Involving every single layer in between is madness.)
  - zaphar 4y ago
    The error here is not that they are wrapping the exception necessarily. It is that they re-threw it as an unchecked exception. I strongly believe the only good use of unchecked exceptions is if the code should do the closest reasonable thing to crash safely. Everything should be clearly communicated to the callers so they can make good decisions about what to handle here and what to pass up the chain. If the complaint is that you then have too many different unchecked exceptions perhaps the error domain has been improperly modeled and you are getting a clue that the system is poorly designed.
    - Quekid5 4y ago
      > The error here is not that they are wrapping the exception necessarily. It is that they re-threw it as an unchecked exception. You often don't have a choice. Think of generic interfaces -- for example the humble apply method on https://docs.oracle.com/javase/8/docs/api/java/util/function/Function.html https://docs.oracle.com/javase/8/docs/api/java/util/function... . If you have a Function which needs to do some interruptible work you cannot throw InterruptedException -- you must wrap it. This is a fundamental design flaw in Java's exception system and cannot be handwaved away just by saying that Function is badly designed. This problem is pervasive. The ultimate problem here is one of variance -- throws clauses have the opposite variance rules from method implementations: Subclasses (whether of interfaces or classes) frequently need to more than could be foreseen by the implementor of the interface, so they need to be able to throw "more things", but checked exception clauses explicitly disallow widening the set of thrown exceptions in subclasses (for obvious reasons -- since a FooImpl can be used a runtime where a Foo is expected). This is a fundamental flaw that was overlooked in the checked exceptions design and there's no fixing it now.
Groxx 4y ago
This is the problem of Java's implementation of checked exceptions... because they are not generic. Which forces middle layers to make impossible decisions like this. If the type system were more capable, they'd just be equivalent to typed generic error returns, which work fine.
- TedDoesntTalk 4y ago
  I mean, can't you just catch Throwable (base class) and be done with it?
  - layer8 4y ago
    This forces client code to handle arbitrary exceptions and it loses the information about which specific exceptions are actually thrown. This is like having Object as the return type on all functions, and having callers do instanceof to see what type of result they got. Exceptions should be part of the semantic contract of functions/methods just like return types are.
    - zaphar 4y ago
      Exceptions are a return type of functions. They return via a different path but there is no possible way you could disagree that they are a form of return.
      - layer8 4y ago
        Exactly my point?
        dllthomas 4y ago
        I understood it to be intended as agreement with emphasis.
      - dllthomas 4y ago
        As they don't return to the same place, don't return to a single place, and may (if not caught) not actually return but instead take down the entire thread, I think it's reasonable that for some purposes it might well make sense to treat exceptions as something other than "a form of return." ¯\_(ツ)_/¯ However we're treating them, however, I agree that they are a part of the interface and should be documented (and, where relevant, checked) as such.
zaphar 4y ago
If it's an unchecked exception experience says I have a 60-70 percent chance of not knowing it's there without a careful reading of the code. Which means I can't know myself if it's possible to handle it or not. I can always rethrow an exception if I know it exists. Languages that give me a way to ensure I know about it means I avoid unnecessary pain later in production with someone breathing down my neck to please fix it now. I'll take that any day over a little boilerplate.

stickfigure 4y ago

And 99.9% of the time the client is just going to catch generic Exception and doesn't care what the type is. Rollback a transaction, return 500 or display an error dialog. Done. It doesn't matter what the client library thinks.

rowls66 4y ago

That is true, so the library should throw the checked exception, and if the caller has no way to handle it, it should wrap the checked exception in an unchecked exception and throw the unchecked exception. Not too hard, and library clients that can handle some checked exceptions will be able to. I hate libraries that only throw unchecked exceptions. It seems easier initially, but makes writing correct code more difficult.

Quekid5 4y ago
> If the caller has no way to handle it, it should wrap the checked exception in an unchecked exception and throw the unchecked exception. Not you have a new problem: How is the code calling the caller supposed to know about that exception? You can't even catch it (even if you know about it!) using normal try-catch because what you have to do is catch the wrapper exception and then check inside that for the exception type you expect via instanceof. Checked exceptions (at least as implemented in Java) are horrible for the composability of code wrt. error handling. That is why most libraries eschew checked exceptions these days. Unfortunately, large bits of the standard library in Java forces their hand wrt. re-wrapping stuff like InterruptedException and IOException and the like. (Not to mention, most of the time you really shouldn't be catching exceptions in very small scopes or at the very highest level in your code. Involving every single layer in between is madness.)
- zaphar 4y ago
  The error here is not that they are wrapping the exception necessarily. It is that they re-threw it as an unchecked exception. I strongly believe the only good use of unchecked exceptions is if the code should do the closest reasonable thing to crash safely. Everything should be clearly communicated to the callers so they can make good decisions about what to handle here and what to pass up the chain. If the complaint is that you then have too many different unchecked exceptions perhaps the error domain has been improperly modeled and you are getting a clue that the system is poorly designed.
  - Quekid5 4y ago
    > The error here is not that they are wrapping the exception necessarily. It is that they re-threw it as an unchecked exception. You often don't have a choice. Think of generic interfaces -- for example the humble apply method on https://docs.oracle.com/javase/8/docs/api/java/util/function/Function.html https://docs.oracle.com/javase/8/docs/api/java/util/function... . If you have a Function which needs to do some interruptible work you cannot throw InterruptedException -- you must wrap it. This is a fundamental design flaw in Java's exception system and cannot be handwaved away just by saying that Function is badly designed. This problem is pervasive. The ultimate problem here is one of variance -- throws clauses have the opposite variance rules from method implementations: Subclasses (whether of interfaces or classes) frequently need to more than could be foreseen by the implementor of the interface, so they need to be able to throw "more things", but checked exception clauses explicitly disallow widening the set of thrown exceptions in subclasses (for obvious reasons -- since a FooImpl can be used a runtime where a Foo is expected). This is a fundamental flaw that was overlooked in the checked exceptions design and there's no fixing it now.

Groxx 4y ago

This is the problem of Java's implementation of checked exceptions... because they are not generic. Which forces middle layers to make impossible decisions like this. If the type system were more capable, they'd just be equivalent to typed generic error returns, which work fine.

TedDoesntTalk 4y ago
I mean, can't you just catch Throwable (base class) and be done with it?
- layer8 4y ago
  This forces client code to handle arbitrary exceptions and it loses the information about which specific exceptions are actually thrown. This is like having Object as the return type on all functions, and having callers do instanceof to see what type of result they got. Exceptions should be part of the semantic contract of functions/methods just like return types are.
  - zaphar 4y ago
    Exceptions are a return type of functions. They return via a different path but there is no possible way you could disagree that they are a form of return.
    - layer8 4y ago
      Exactly my point?
      - dllthomas 4y ago
        I understood it to be intended as agreement with emphasis.
    - dllthomas 4y ago
      As they don't return to the same place, don't return to a single place, and may (if not caught) not actually return but instead take down the entire thread, I think it's reasonable that for some purposes it might well make sense to treat exceptions as something other than "a form of return." ¯\_(ツ)_/¯ However we're treating them, however, I agree that they are a part of the interface and should be documented (and, where relevant, checked) as such.

zaphar 4y ago

If it's an unchecked exception experience says I have a 60-70 percent chance of not knowing it's there without a careful reading of the code. Which means I can't know myself if it's possible to handle it or not. I can always rethrow an exception if I know it exists. Languages that give me a way to ensure I know about it means I avoid unnecessary pain later in production with someone breathing down my neck to please fix it now. I'll take that any day over a little boilerplate.