17 ms·

Put another way: errors tend to either be handled "close by" or "far away", but rarely "in the middle". So Java's checked exceptions force you to write verbose

• Jensson 1y ago
  > So Java's checked exceptions force you to write verbose and pointless code in all the wrong places (the "in the middle" code that can't handle and doesn't care about the exception). It doesn't, you can just declare that the function throws these as well, you don't have to handle it directly.
  • wavemode 1y ago
    It pollutes type signatures. If some method deep down the call stack changes its implementation details from throwing exception A you don't care about to throwing exception B you also don't care about, you also have to change the type of `throws` annotation on your method. This is annoying enough to deal with in concrete code, but interfaces make it a nightmare.
    • pjmlp 1y ago
      You mean like using Result with a long list of possible errors, thus having crates that handle this magically with macros?
      • wavemode 1y ago
        Yes, the exact same problem is present in languages where "errors are just values". To solve this, Rust does allow you to just Box<dyn Error> (or equivalents like anyhow). And Go has the Error interface. People who list out all concrete error types are just masochists.
        • pjmlp 1y ago
          Go as usual, got this clever idea to use strings and having people parse error messages. It took until version 1.13 to have something better, and even now too many people still do errors.New("....."), because so is Go world.