3 ms·

Dave Cheney gave a talk about error handling in Go that sheds some light on how the Go community thinks about errors: https://www.youtube.com/watch?v=lsBF58Q-D

Dave Cheney gave a talk about error handling in Go that sheds some light on how the Go community thinks about errors: https://www.youtube.com/watch?v=lsBF58Q-DnY https://www.youtube.com/watch?v=lsBF58Q-DnY

knocte 10y ago
Wow, that talk just demonstrates that all downsides about error handling in Go are due to its lack of exceptions (at least how they work in languages like C#). It's a step backwards, it's ludicrous.
pmarreck 10y ago
I watched this, and what I saw was a heck of a lot of information about how to extract information from error values and percolate them together up to a handler, all of which would automatically be present in your everyday stack trace in a language that actually threw unexpected runtime errors. ;) I frankly don't see how this is OK, nor better. Errors are real in the sense that they are evidence that the programmer's mental model of state did not line up with the actual state (usually in some corner case). There is literally NO circumstance in which being in a programmer-unknown state (yet still "alive" so to speak) is better than being in a programmer-known-and-accounted-for state. (For an example of being in a programmer-unknown yet alive state, see: Every Security Hole Ever.) This is why "throwing" is appropriate, no matter how much the Go creator didn't like it. If even a single runtime error goes undetected/unhandled, you will end up further and further into an unknown state due to state corruption, and your behavior will soon become completely nondeterministic (or at least, nondeterministic-appearing). Losing determinism is the first step on the road to dragons. I literally can't see how this wouldn't happen, and what I AM seeing is a lot of chatter in Go communities about how to manage this problem, when the solution is already there: Just fucking throw a stack trace. Or, even better, do what Erlang/Elixir do: Throw it, log it, and have a supervisor process kill it and restart it, all in 1 millisecond or less. If the error keeps happening above a certain threshold rate, kill and restart the supervisor as well. The reason this works (and has resulted in the INSANE uptimes that Erlang-backed services have) is that it resets state to programmer-known conditions.
- sdegutis 10y ago
  I don't think the original Go authors ever truly thought that exceptions are "bad" per se. I think they just took it off the table because of the complexity it added to the language, both conceptually and implementation wise. A (the?) primary main goal of Go from the beginning has always been to make implementation as obvious as possible; in other words, to make it a slightly thicker layer on top of assembly than C was (they seemed to like Java 1's idea of interfaces), while still keeping in mind that it will map to assembly. The language's design is inherently tied to its compilation model. And to add exceptions would add complexity to it which for some reason they considered to be "too much". Same story with generics fwiw.
  - johncolanduoni 10y ago
    To whom is the implementation of a generational, concurrent GC obvious? It requires a lot of compiler infrastructure and complex runtime support, much more than stack unwinding. I'm not a fan of, say C#'s, exception model, but it's far from the complexity of features Go already has in either implementation or programmer understanding. On top of that, unwinding isn't the only way to get something where errors have to be handled or the program dies. Look at Swift's error handling for example: it's basically sugar over returned errors with correctness checks. Dead simple implementation, and dead simple to explain to users. What I don't buy about the justifications for Go's design is that they were driven by the pure guiding hand of simplicity. It looks more to me like the designers simply treated language features they had seen done badly before as anathema and didn't try to think about how the mistakes could be corrected.
- maleck13 10y ago
  You do also have panic available which is for exceptional cases

knocte 10y ago

Wow, that talk just demonstrates that all downsides about error handling in Go are due to its lack of exceptions (at least how they work in languages like C#). It's a step backwards, it's ludicrous.

pmarreck 10y ago

I watched this, and what I saw was a heck of a lot of information about how to extract information from error values and percolate them together up to a handler, all of which would automatically be present in your everyday stack trace in a language that actually threw unexpected runtime errors. ;) I frankly don't see how this is OK, nor better. Errors are real in the sense that they are evidence that the programmer's mental model of state did not line up with the actual state (usually in some corner case). There is literally NO circumstance in which being in a programmer-unknown state (yet still "alive" so to speak) is better than being in a programmer-known-and-accounted-for state. (For an example of being in a programmer-unknown yet alive state, see: Every Security Hole Ever.) This is why "throwing" is appropriate, no matter how much the Go creator didn't like it. If even a single runtime error goes undetected/unhandled, you will end up further and further into an unknown state due to state corruption, and your behavior will soon become completely nondeterministic (or at least, nondeterministic-appearing). Losing determinism is the first step on the road to dragons. I literally can't see how this wouldn't happen, and what I AM seeing is a lot of chatter in Go communities about how to manage this problem, when the solution is already there: Just fucking throw a stack trace. Or, even better, do what Erlang/Elixir do: Throw it, log it, and have a supervisor process kill it and restart it, all in 1 millisecond or less. If the error keeps happening above a certain threshold rate, kill and restart the supervisor as well. The reason this works (and has resulted in the INSANE uptimes that Erlang-backed services have) is that it resets state to programmer-known conditions.

sdegutis 10y ago
I don't think the original Go authors ever truly thought that exceptions are "bad" per se. I think they just took it off the table because of the complexity it added to the language, both conceptually and implementation wise. A (the?) primary main goal of Go from the beginning has always been to make implementation as obvious as possible; in other words, to make it a slightly thicker layer on top of assembly than C was (they seemed to like Java 1's idea of interfaces), while still keeping in mind that it will map to assembly. The language's design is inherently tied to its compilation model. And to add exceptions would add complexity to it which for some reason they considered to be "too much". Same story with generics fwiw.
- johncolanduoni 10y ago
  To whom is the implementation of a generational, concurrent GC obvious? It requires a lot of compiler infrastructure and complex runtime support, much more than stack unwinding. I'm not a fan of, say C#'s, exception model, but it's far from the complexity of features Go already has in either implementation or programmer understanding. On top of that, unwinding isn't the only way to get something where errors have to be handled or the program dies. Look at Swift's error handling for example: it's basically sugar over returned errors with correctness checks. Dead simple implementation, and dead simple to explain to users. What I don't buy about the justifications for Go's design is that they were driven by the pure guiding hand of simplicity. It looks more to me like the designers simply treated language features they had seen done badly before as anathema and didn't try to think about how the mistakes could be corrected.
maleck13 10y ago
You do also have panic available which is for exceptional cases