4 ms·

Many threaded languages throw an exception that can be caught and if not caught, kills that thread. Not the whole program. See Java, C#, etc.

Thaxll 6y ago
If not cought you end up in a really bad state.
- recursive 6y ago
  If you don't catch it, you generally don't end up in a bad state. More like a lack of a state altogether.
- apta 6y ago
  Any well-written framework will have a base-level exception handler. If not, it will simply exit the program with a trace. Compare that with actually ending up with bad state in golang if errors are accidentally ignored or overwritten (I've seen it happen several times). golang errors are strictly inferior.
stickfigure 6y ago
And in practice, with Java, C#, etc programs, there's a high level catch that prevents anything terrible from happening. Http requests return 500, UI threads show an error dialog, etc. In almost all business processing, thanks to the magic of transactions, you never end up in a bad state.
- spullara 6y ago
  The one thing that I don't think either has tackled is that things like OOM can leave synchronized blocks in a bad state. There are certain errors which should kill the whole process which is why they have the flag that lets you do that. But for more mundane errors, you have an escape hatch.
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.)
to11mtm 6y ago
Slightly pedantic point: In the case of C#, not observing an exception (i.e. catching or thrown by another thread could kill the whole program before .NET 4.5. But this was pretty easy to guard around in various, even easy (if sloppy) ways.

Thaxll 6y ago

If not cought you end up in a really bad state.

recursive 6y ago
If you don't catch it, you generally don't end up in a bad state. More like a lack of a state altogether.
apta 6y ago
Any well-written framework will have a base-level exception handler. If not, it will simply exit the program with a trace. Compare that with actually ending up with bad state in golang if errors are accidentally ignored or overwritten (I've seen it happen several times). golang errors are strictly inferior.

stickfigure 6y ago

And in practice, with Java, C#, etc programs, there's a high level catch that prevents anything terrible from happening. Http requests return 500, UI threads show an error dialog, etc. In almost all business processing, thanks to the magic of transactions, you never end up in a bad state.

spullara 6y ago
The one thing that I don't think either has tackled is that things like OOM can leave synchronized blocks in a bad state. There are certain errors which should kill the whole process which is why they have the flag that lets you do that. But for more mundane errors, you have an escape hatch.

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.)

to11mtm 6y ago

Slightly pedantic point: In the case of C#, not observing an exception (i.e. catching or thrown by another thread could kill the whole program before .NET 4.5. But this was pretty easy to guard around in various, even easy (if sloppy) ways.