4 ms·

Disagree. Semantically if you are wrapping an error it means you that you are purposely shifting the responsibility and declaring that your function is responsi

Disagree. Semantically if you are wrapping an error it means you that you are purposely shifting the responsibility and declaring that your function is responsible for the failure. If you instead re-throw the error, such as if was an IOException, semantically it means that you are not responsible for the error and that the calling code should deal it. If later on you need to add a new thrown exception, it does result in a breaking change on upgrade but it should, as new errors should be thoughtfully handled. The real culprit is that most people realize that they are not building rockets and thus think that errors, recovery from error and mitigating data loss are not worth their time. Just because I’m not writing a rocket schematic does not mean it’s okay that you lose my 2 hours of work, or that PagerDuty alerts go off at 2am because there was one blip and the database is now slightly corrupted, or you put my account into an undefined state where I have to beg support for help. If errors are checked, many people just wrap all errors will-nilly. If errors are not checked, they never bother with sensible error handling. To me, whether a language has checked errors or not is just feature of the tool, and whether someone uses tools correctly or not is up to the user.

wvenable 2y ago
> Semantically if you are wrapping an error it means you that you are purposely shifting the responsibility and declaring that your function is responsible for the failure. I don't understand what this means. If you wrap an exception and throw it, how has your function become responsible for the failure? > If errors are not checked, they never bother with sensible error handling. My most robust desktop application has a single exception handler at the event loop that puts the exception message in a messagebox. Try and save your file to a network location that doesn't exist anymore? Click OK and try again. > To me, whether a language has checked errors or not is just feature of the tool You didn't address the criticism that checked exceptions are fundamentally incompatible with other features such as higher order functions and polymorphism. It's an experiment that has ultimately failed in practice.
- kaba0 2y ago
  > I don't understand what this means. If you wrap an exception and throw it, how has your function become responsible for the failure? That’s a declaration that this specific kind of problem (say, an IOException) can be handled as this other, higher-level exception (say, of type MyApplicationException, that when bubbles up, will display a friendly error dialog to the user, and logs the underlying IOException for the devs). > checked exceptions are fundamentally incompatible with [..] higher order functions and polymorphism They aren’t. Look into languages with algebraic effects.
  - wvenable 2y ago
    Maybe I know how to handle IOException but not MyApplicationException but the method only gives me the latter. There is effectively no handling MyApplicationException so why even force the declaration. Either way most exceptions cannot be handled in any meaningful way anyway so checked exceptions are pointless busywork. > They aren’t. Look into languages with algebraic effects. Can you give me more to go on than that?

wvenable 2y ago

> Semantically if you are wrapping an error it means you that you are purposely shifting the responsibility and declaring that your function is responsible for the failure. I don't understand what this means. If you wrap an exception and throw it, how has your function become responsible for the failure? > If errors are not checked, they never bother with sensible error handling. My most robust desktop application has a single exception handler at the event loop that puts the exception message in a messagebox. Try and save your file to a network location that doesn't exist anymore? Click OK and try again. > To me, whether a language has checked errors or not is just feature of the tool You didn't address the criticism that checked exceptions are fundamentally incompatible with other features such as higher order functions and polymorphism. It's an experiment that has ultimately failed in practice.

kaba0 2y ago
> I don't understand what this means. If you wrap an exception and throw it, how has your function become responsible for the failure? That’s a declaration that this specific kind of problem (say, an IOException) can be handled as this other, higher-level exception (say, of type MyApplicationException, that when bubbles up, will display a friendly error dialog to the user, and logs the underlying IOException for the devs). > checked exceptions are fundamentally incompatible with [..] higher order functions and polymorphism They aren’t. Look into languages with algebraic effects.
- wvenable 2y ago
  Maybe I know how to handle IOException but not MyApplicationException but the method only gives me the latter. There is effectively no handling MyApplicationException so why even force the declaration. Either way most exceptions cannot be handled in any meaningful way anyway so checked exceptions are pointless busywork. > They aren’t. Look into languages with algebraic effects. Can you give me more to go on than that?