6 ms·

I get that the error is still propagated "manually" behind the scene; but how is this different from exceptions in practice once you use try everywhere (except

• tedunangst 7y ago
  The error can't go through a function that doesn't return an error, unlike exceptions. Also, you have to ask for this. Reversing the default is a big difference.
  • deleted 7y ago
    [deleted]
  • nmadden 7y ago
    Unlike unchecked exceptions.
    • tedunangst 7y ago
      Even with checked exceptions, you have to be careful. You may not want exceptions from every function you call to fly up to the caller. function X() throws Oops { okToFail(); // fine if this failure goes up unexpectedFailure(); // not fine to go up } Unfortunately, once you tell the compiler its ok for exeptions to go up, that rule applies to the whole function.
      • nmadden 7y ago
        I’m sure that’s a common problem.
• arcticbull 7y ago
  Exceptions are the opposite of a goto statement, basically a 'comes-from' statement. They violate the principal of least surprise in every way possible -- you may have no idea what type is being sent your way, where from or what to meaningfully do about it as a result. They often result in memory leaks in languages like C++ due to lack of destructor invocation. try() errors can only propagate to the caller. As such, stack unwinding is clear, no memory issues arise, performance is good and locality of error is preserved. Surprise is minimized. While it may look similar, it's pretty markedly different in important ways.
  • eecc 7y ago
    Unchecked exceptions... checked ones are basically a bifunctor with a wacky syntax
  • jacques_chester 7y ago
    > you may have no idea what type is being sent your way, where from or what to meaningfully do about it as a result. How is this different from (a) errors bubbling up with a pile of concatenated strings as the only type information or (b) errors not bubbling up because someone decided they would never make a mistake? The whole value of exceptions, to me, is consistency. The error is guaranteed to propagate in a consistent way up the stack. Static type analysis has a fighting chance of predicting what could ever propagate up the stack, whether checked or unchecked. Trying to work out out what `err` might be in various situations is an exercise in forensic grepping. Trying to react intelligently and reliably to different types of error is an exercise in hoping nobody changes the error string.
    • codr7 7y ago
      There's no need to unwind the stack to get what you want. Restarts [0] evaluate the error handler in the throwing scope/environment and the only way out of there is invoking a predefined restart or aborting the program. [0] https://github.com/codr7/g-fu/blob/master/v1/doc/typical_restarts.md https://github.com/codr7/g-fu/blob/master/v1/doc/typical_res...
• grey-area 7y ago
  Because it doesn’t skip the call chain - each function must explicitly handle the error or pass it on. In practice usually errors are handled one or two levels up, not with some global error handler as people do with exceptions. Also the error is in the function signature, unlike exceptions. Also, you don’t use try everywhere, that’s the point. They could do with some better examples.
  • coldtea 7y ago
    >Because it doesn’t skip the call chain - each function must explicitly handle the error or pass it on So like, checked exceptions? >Also the error is in the function signature, unlike exceptions. So like, checked exceptions?
    • grey-area 7y ago
      Sure, there are different ways of doing this. But the OP didn't say 'checked exceptions'.
    • deleted 7y ago
      [deleted]
• coldtea 7y ago
  >I get that the error is still propagated "manually" behind the scene; but how is this different from exceptions in practice once you use try everywhere For one, the Go team hasn't invented exceptions, so they don't fit the NIH goals.