4 ms·

That's the same as Go panic's tho. (Go panics are extremely close to exceptions: the only difference is they can only be caught at function boundaries instead o

by dilap 6y ago

That's the same as Go panic's tho. (Go panics are extremely close to exceptions: the only difference is they can only be caught at function boundaries instead of scope boundaries.) The main difference is cultural: you're encouraged to use return codes for expected error conditions and only panic for program bugs. But there's the temptation to not do that because panic(/exceptions) are more ergonomic. I think exceptions tend to be OK in areas where you don't really care about handling errors: eg command-line tools, GUIs. But for long-lived proccesses, like servers, where it's important to handle errors in a precise way, they are painful, in my experience.

freeone3000 6y ago
Not really. There's a root exception type, which is caught by any framework worth its salt to prevent the scenario described above from breaking program flow for other executing fibers.
- dilap 6y ago
  Hmm, I think it's the same still. Go doesn't have type heirchies, but you can "catch" (recover in Go parlance) any panicked value. It's exactly equivalent, no?
  - apta 6y ago
    To an extent, but you end up getting the worst of both worlds (and then some). You end up having to "catch" panics at the handler level anyway, and end up with verbose and very error-prone error handling in the code.
    - dilap 6y ago
      I'd disagree, personally. I much prefer the explicit error-handling style of Go, even if I also have to handle panics. Errors are explicit; panics (which are program bugs, and can't be handled) are implicit. But program bugs are always implicit. To put it more concretely, my experience has been it is easier to write correct code using the error return style of Go than the exception style of Python or C#. (And though I sadly haven't had an opportunity to use them for "real work," the explicit-error-return-with-ergonomic-syntax regimes of Rust/Zig/Haskell seem even nicer.)
  - deleted 6y ago
    [deleted]

by dilap 6y ago

freeone3000 6y ago

Not really. There's a root exception type, which is caught by any framework worth its salt to prevent the scenario described above from breaking program flow for other executing fibers.

dilap 6y ago
Hmm, I think it's the same still. Go doesn't have type heirchies, but you can "catch" (recover in Go parlance) any panicked value. It's exactly equivalent, no?
- apta 6y ago
  To an extent, but you end up getting the worst of both worlds (and then some). You end up having to "catch" panics at the handler level anyway, and end up with verbose and very error-prone error handling in the code.
  - dilap 6y ago
    I'd disagree, personally. I much prefer the explicit error-handling style of Go, even if I also have to handle panics. Errors are explicit; panics (which are program bugs, and can't be handled) are implicit. But program bugs are always implicit. To put it more concretely, my experience has been it is easier to write correct code using the error return style of Go than the exception style of Python or C#. (And though I sadly haven't had an opportunity to use them for "real work," the explicit-error-return-with-ergonomic-syntax regimes of Rust/Zig/Haskell seem even nicer.)
- deleted 6y ago
  [deleted]