10 ms·

Wasn't this argument used all the time by the Go community. I.e. only use panic when you intend the program to halt, and handle all potential problems with the

Wasn't this argument used all the time by the Go community. I.e. only use panic when you intend the program to halt, and handle all potential problems with the Error type. I think Rob Pike even said it's easy to see where a program fail in one of his talks? But to me the superb thing about exceptions, is that error handling can be done where it makes sense. I.e. we can try{ problem-code }catch(problem){ handle problem } in a single location. Otherwise we end up peppering the entire code base with a ton of error checking far down the call stack, where we really cannot do much about the problem anyway (unless we are writing command line tools where error handling is just writing the problem to stderr). Exceptions gives us a nice way to let problems bubble up to the surface, while also stating what the problem was, and where it occurred. That is great IMO.

oconnor663 4y ago
> Exceptions gives us a nice way to let problems bubble up to the surface, while also stating what the problem was, and where it occurred. Work is ongoing on some of this, but there are popular libraries in Rust (like `anyhow`) that let you attach backtraces to regular errors, add context, etc. Propagating erros to callers is handled with the standard `?` operator, which means "short-circuit and return this if it was an error, otherwise give me the successful result". This has the benefit of making early exits explicit, without interrupting the visual flow of straight-line code.
- bjarneh 4y ago
  OK, I'm not into Rust. It just seems a bit too complicated :-)
  - pornel 4y ago
    The simple explanation is that Rust has an equivalent of Java-style exceptions of "throw here, handle elsewhere", but has a different syntax for this. Instead of try/catch, there's a `?` operator to return ("rethrow") the error to an outer scope. It's a better fit for Rust's use of a generic Result type, but overall its usage is similar to the checked exceptions in Java. Because Rust uses the type-safe explicit Result/? approach for all non-bug failures in the program, the implicit panic (that behaves similarly to RuntimeException in Java) is reserved for assertion failures and crashes only. `catch_unwind` is not guaranteed to work in Rust. There's a setting to disable it and always hard abort() the whole process on every panic. Rust is serious with panics being for programmer's bugs only, and not trivialities like "file not found".
    - bjarneh 4y ago
      Thanks for the explanation. I guess most languages need this feature i.e. fail anywhere below this call, then return the type error + where it occurred + a stack trace. I've even heard of people doing stuff like that in C, where they store the stack trace in a list they populate and return errors as part of the same struct, in order to have something similar to exceptions. I have to say I really enjoyed Rust when it was in its infancy (version 0.1 - 0.2 or thereabouts), but have since fallen off. It used to be so simple and so clean, and unlike anything else. Today it's just way to complex for me :-)
vetinari 4y ago
> But to me the superb thing about exceptions, is that error handling can be done where it makes sense. Not necessarily. With exceptions, it is easy to be a cause of error and just throw the exception, then expect up the stack to handle it. Which of course has no idea how, it didn't control the cause in the first place. Forcing error handling as near as where error can happen prevents this.
- bjarneh 4y ago
  > it is easy to be a cause of error and just throw the exception, then expect up the stack to handle it. Agree, this can happen. Perhaps the bad attempt at fixing this in Java for instance - checked exceptions, made people dislike exceptions ever more. The caller "has to handle" the exceptions or re-throw them of course. Even though RuntimeException's can come from anywhere at anytime, so "guard" provided by checked exceptions just made a complete mess of things. People are lulled into thinking that methods without the 'throws BlaBlaException' signature are safe and so on. I guess no language is 100% on everything, but I've always felt that exceptions are one thing I really like; especially when a language manages to do them correctly.
- native_samples 4y ago
  Actually, up the stack is usually the only place that knows how to handle the error. For instance sometimes dumping to stderr is the right thing to do, other times logging it, other times displaying a generic crash GUI, sometimes display a customized UI. There may also be times when the exception can be handled in a better way, with fallbacks for example. The Rust/Go approach always makes me laugh. Normally in engineering or anything where reliability matters, panicking is understood to be a bad thing to do and people go through extensive training to ensure they don't do it. Somehow these language communities decided that panicking and giving up on the spot is a smart behaviour.
  - jeddy3 4y ago
    > Somehow these language communities decided that panicking and giving up on the spot is a smart behaviour. Oh, come on, that's a straw man. Just because panic! exists as a "abort-program-with-a-message", does not mean it's somehow encouraged above using idiomatic error handling. Just as you can do the same thing in languages with exceptions. Sometimes exiting the program is the right thing to do.

oconnor663 4y ago

> Exceptions gives us a nice way to let problems bubble up to the surface, while also stating what the problem was, and where it occurred. Work is ongoing on some of this, but there are popular libraries in Rust (like `anyhow`) that let you attach backtraces to regular errors, add context, etc. Propagating erros to callers is handled with the standard `?` operator, which means "short-circuit and return this if it was an error, otherwise give me the successful result". This has the benefit of making early exits explicit, without interrupting the visual flow of straight-line code.

bjarneh 4y ago
OK, I'm not into Rust. It just seems a bit too complicated :-)
- pornel 4y ago
  The simple explanation is that Rust has an equivalent of Java-style exceptions of "throw here, handle elsewhere", but has a different syntax for this. Instead of try/catch, there's a `?` operator to return ("rethrow") the error to an outer scope. It's a better fit for Rust's use of a generic Result type, but overall its usage is similar to the checked exceptions in Java. Because Rust uses the type-safe explicit Result/? approach for all non-bug failures in the program, the implicit panic (that behaves similarly to RuntimeException in Java) is reserved for assertion failures and crashes only. `catch_unwind` is not guaranteed to work in Rust. There's a setting to disable it and always hard abort() the whole process on every panic. Rust is serious with panics being for programmer's bugs only, and not trivialities like "file not found".
  - bjarneh 4y ago
    Thanks for the explanation. I guess most languages need this feature i.e. fail anywhere below this call, then return the type error + where it occurred + a stack trace. I've even heard of people doing stuff like that in C, where they store the stack trace in a list they populate and return errors as part of the same struct, in order to have something similar to exceptions. I have to say I really enjoyed Rust when it was in its infancy (version 0.1 - 0.2 or thereabouts), but have since fallen off. It used to be so simple and so clean, and unlike anything else. Today it's just way to complex for me :-)

vetinari 4y ago

> But to me the superb thing about exceptions, is that error handling can be done where it makes sense. Not necessarily. With exceptions, it is easy to be a cause of error and just throw the exception, then expect up the stack to handle it. Which of course has no idea how, it didn't control the cause in the first place. Forcing error handling as near as where error can happen prevents this.

bjarneh 4y ago
> it is easy to be a cause of error and just throw the exception, then expect up the stack to handle it. Agree, this can happen. Perhaps the bad attempt at fixing this in Java for instance - checked exceptions, made people dislike exceptions ever more. The caller "has to handle" the exceptions or re-throw them of course. Even though RuntimeException's can come from anywhere at anytime, so "guard" provided by checked exceptions just made a complete mess of things. People are lulled into thinking that methods without the 'throws BlaBlaException' signature are safe and so on. I guess no language is 100% on everything, but I've always felt that exceptions are one thing I really like; especially when a language manages to do them correctly.
native_samples 4y ago
Actually, up the stack is usually the only place that knows how to handle the error. For instance sometimes dumping to stderr is the right thing to do, other times logging it, other times displaying a generic crash GUI, sometimes display a customized UI. There may also be times when the exception can be handled in a better way, with fallbacks for example. The Rust/Go approach always makes me laugh. Normally in engineering or anything where reliability matters, panicking is understood to be a bad thing to do and people go through extensive training to ensure they don't do it. Somehow these language communities decided that panicking and giving up on the spot is a smart behaviour.
- jeddy3 4y ago
  > Somehow these language communities decided that panicking and giving up on the spot is a smart behaviour. Oh, come on, that's a straw man. Just because panic! exists as a "abort-program-with-a-message", does not mean it's somehow encouraged above using idiomatic error handling. Just as you can do the same thing in languages with exceptions. Sometimes exiting the program is the right thing to do.