3 ms·

Throwing exceptions in out-of-memory cases or something similar has no sense, since no real program can handle such exceptions properly. Throwing exceptions in

Throwing exceptions in out-of-memory cases or something similar has no sense, since no real program can handle such exceptions properly. Throwing exceptions in cases of logic errors (like accessing an array with invalid index) has no sense, since they just conceal bugs. In other cases it's unclear what is exceptional and what is not. So why not just using normal control flow? That's why I personally use no exceptions (I program mostly in C++ and Rust).

xg15 1y ago
> Throwing exceptions in cases of logic errors (like accessing an array with invalid index) has no sense, since they just conceal bugs. Catching (and not logging) the exception would conceal the bug, but I wouldn't want to get rid of the stacktrace that comes with throwing the exception - that is extremely useful for narrowing down the location of the bug. Incidentally, that's something I've never understood in the "Go style error handling" crowd. The default behavior - if you ignore the return value - in those languages is exactly equivalent to catching and silently throwing away an exception - the thing that's universally understood to be a bad idea. Whereas the default behavior in languages with exceptions is to print the error and exit the program - which us usually seen as the safest choice, unless you have more information and can recover from the exception. So if go-style error handling makes it easier to do the bad thing instead of the good thing, why would it still be the superior form of error handling?
- Panzerschrek 1y ago
  Catching exceptions caused by a bug has no sense in production code. For debugging purposes exceptions aren't necessary, a compiler can just insert asserts and call stack printing at the place where a bug was detected. I agree that errors handling as it is implemented in Go is error-prone. Rust does this much better - values of a Result type shouldn't be discarded.
  - xg15 1y ago
    > For debugging purposes exceptions aren't necessary, a compiler can just insert asserts and call stack printing at the place where a bug was detected. For that, you'd have to know the location in the first place, which you usually don't.
  - samus 1y ago
    You are not supposed to catch such exceptions in the first place, except at the very top level as a fallback to implement proper logging and to signal an unexpected internal error to the user. In Java, such exceptions are subclasses of RuntimeException. Just printing a warning is not always appropriate. The code would continue to work and produce invalid data and actions.

xg15 1y ago

> Throwing exceptions in cases of logic errors (like accessing an array with invalid index) has no sense, since they just conceal bugs. Catching (and not logging) the exception would conceal the bug, but I wouldn't want to get rid of the stacktrace that comes with throwing the exception - that is extremely useful for narrowing down the location of the bug. Incidentally, that's something I've never understood in the "Go style error handling" crowd. The default behavior - if you ignore the return value - in those languages is exactly equivalent to catching and silently throwing away an exception - the thing that's universally understood to be a bad idea. Whereas the default behavior in languages with exceptions is to print the error and exit the program - which us usually seen as the safest choice, unless you have more information and can recover from the exception. So if go-style error handling makes it easier to do the bad thing instead of the good thing, why would it still be the superior form of error handling?

Panzerschrek 1y ago
Catching exceptions caused by a bug has no sense in production code. For debugging purposes exceptions aren't necessary, a compiler can just insert asserts and call stack printing at the place where a bug was detected. I agree that errors handling as it is implemented in Go is error-prone. Rust does this much better - values of a Result type shouldn't be discarded.
- xg15 1y ago
  > For debugging purposes exceptions aren't necessary, a compiler can just insert asserts and call stack printing at the place where a bug was detected. For that, you'd have to know the location in the first place, which you usually don't.
- samus 1y ago
  You are not supposed to catch such exceptions in the first place, except at the very top level as a fallback to implement proper logging and to signal an unexpected internal error to the user. In Java, such exceptions are subclasses of RuntimeException. Just printing a warning is not always appropriate. The code would continue to work and produce invalid data and actions.