4 ms·

> hey encourage developers to really think about what happens in the failure case. It's a noble goal, but once I started thinking about what happens in the fai

> hey encourage developers to really think about what happens in the failure case. It's a noble goal, but once I started thinking about what happens in the failure case, I came to the conclusion that checked exceptions are no help here: - there are always unchecked exceptions. I found it useful to think that any function might throw. So if extra reporting or graceful shutdown are required, just catch everything - in most cases I have no idea how to recover from error: just keep throwing it to the caller until someone knows what to do. I want it to be the default behavior and I don't want to clutter my code with all the catch-wrap-rethrow boilerplate.

hota_mazi 6y ago
> in most cases I have no idea how to recover from error: just keep throwing it to the caller until someone knows what to do. I want it to be the default behavior and I don't want to clutter my code with all the catch-wrap-rethrow boilerplate. What's your alternative? Using return values? But then you are doing the bubbling, manually. Exceptions offer a more elegant and less boiler plate approach to this problem: if your code can't handle an exception, just declare it in your signature and ignore it. This is really the best approach to this problem: - The error cases are part of the function's signature (as they should). - The language takes care of bringing the exception to the right handler. - Your code can proceed with the assumption that all the values are sound.
- aeternum 6y ago
  I've found that in practice it leads to very generic exception names. When a new failure mode is found for a lowlevel component, in other languages devs would add a new specific exception and things would generally work. In Java, devs have to modify every intermediate component to handle or pass the new exception type so they end up just using an existing one that is super generic.
- 0xffff2 6y ago
  >What's your alternative? Using return values? But then you are doing the bubbling, manually. Huh? The alternative is unchecked exceptions, which are already present in Java and therefore have to be accounted for anyway. Removing checked exceptions from Java would greatly simplify the APIs that use them, with absolutely zero cost.
- sreque 6y ago
  Return values are a million times better than checked exceptions because return values compose and return values don't collide with the rest of the langugage. Checked exceptions are basically monads but with all the disadvantages of monads but none of the advantages. There is a reason no language since has copied them.
  - ragnese 6y ago
    Except that many languages just do worse. Go, Kotlin, Clojure (very different philosophy, though), C#...
    - sreque 6y ago
      IMO the solution is to either: * Use return values and let people deal with the boilerplate ala Optional in java. We use Optionals to replace null values and IMO the boilerplate is 100% worth it. I've also used return values that can encode possible errors in Java. * Use unchecked exceptions and expect people to understand the methods they call and the exceptions those methods can throw, which should be documented in javadoc instead of a throws clause. This needs to happen regardless, as methods can throws unchecked exceptions the caller might need to be aware of, so this in reality doesn't involve extra work. For me, either of these solutions is preferrable to checked exceptions.
      - ragnese 6y ago
        Agreed that the boilerplate of Optional is worth it. That doesn't mean it's actually good. With Java it's just a choice between "bad" and "worse".
  - hota_mazi 6y ago
    > Return values are a million times better than checked exceptions because return values compose No they don't, not even when they're monads (you need monad transformers to compose monads since they don't universally compose).
    - 6y ago
mcguire 6y ago
Unchecked exceptions were intended for problems that your code shouldn't really be expected to handle; catching them at the top-level, reporting the error, and letting the user figure out what to is about the only reasonable answer. Checked exceptions are part of your API, things that your code should be dealing with, and catch-wrap-rethrow is often the right thing. It only becomes a problem with Java programmer's tendency towards thin, shallow abstractions.
alasdair_ 6y ago
> there are always unchecked exceptions I’m not sure this is necessarily true. There are always unchecked Throwable’s, but exceptions and Errors are quite distinct things.

hota_mazi 6y ago

> in most cases I have no idea how to recover from error: just keep throwing it to the caller until someone knows what to do. I want it to be the default behavior and I don't want to clutter my code with all the catch-wrap-rethrow boilerplate. What's your alternative? Using return values? But then you are doing the bubbling, manually. Exceptions offer a more elegant and less boiler plate approach to this problem: if your code can't handle an exception, just declare it in your signature and ignore it. This is really the best approach to this problem: - The error cases are part of the function's signature (as they should). - The language takes care of bringing the exception to the right handler. - Your code can proceed with the assumption that all the values are sound.

aeternum 6y ago
I've found that in practice it leads to very generic exception names. When a new failure mode is found for a lowlevel component, in other languages devs would add a new specific exception and things would generally work. In Java, devs have to modify every intermediate component to handle or pass the new exception type so they end up just using an existing one that is super generic.
0xffff2 6y ago
>What's your alternative? Using return values? But then you are doing the bubbling, manually. Huh? The alternative is unchecked exceptions, which are already present in Java and therefore have to be accounted for anyway. Removing checked exceptions from Java would greatly simplify the APIs that use them, with absolutely zero cost.
sreque 6y ago
Return values are a million times better than checked exceptions because return values compose and return values don't collide with the rest of the langugage. Checked exceptions are basically monads but with all the disadvantages of monads but none of the advantages. There is a reason no language since has copied them.
- ragnese 6y ago
  Except that many languages just do worse. Go, Kotlin, Clojure (very different philosophy, though), C#...
  - sreque 6y ago
    IMO the solution is to either: * Use return values and let people deal with the boilerplate ala Optional in java. We use Optionals to replace null values and IMO the boilerplate is 100% worth it. I've also used return values that can encode possible errors in Java. * Use unchecked exceptions and expect people to understand the methods they call and the exceptions those methods can throw, which should be documented in javadoc instead of a throws clause. This needs to happen regardless, as methods can throws unchecked exceptions the caller might need to be aware of, so this in reality doesn't involve extra work. For me, either of these solutions is preferrable to checked exceptions.
    - ragnese 6y ago
      Agreed that the boilerplate of Optional is worth it. That doesn't mean it's actually good. With Java it's just a choice between "bad" and "worse".
- hota_mazi 6y ago
  > Return values are a million times better than checked exceptions because return values compose No they don't, not even when they're monads (you need monad transformers to compose monads since they don't universally compose).
  - 6y ago

mcguire 6y ago

Unchecked exceptions were intended for problems that your code shouldn't really be expected to handle; catching them at the top-level, reporting the error, and letting the user figure out what to is about the only reasonable answer. Checked exceptions are part of your API, things that your code should be dealing with, and catch-wrap-rethrow is often the right thing. It only becomes a problem with Java programmer's tendency towards thin, shallow abstractions.

alasdair_ 6y ago

> there are always unchecked exceptions I’m not sure this is necessarily true. There are always unchecked Throwable’s, but exceptions and Errors are quite distinct things.