6 ms·

That's fair, but I don't feel that Go's position of biasing to the absolute opposite end of the spectrum is reasonable. Ultimately; in a typical app; if you've

by 015a 4y ago

That's fair, but I don't feel that Go's position of biasing to the absolute opposite end of the spectrum is reasonable. Ultimately; in a typical app; if you've got a phrase of code like: result, err := db.GetUser("12345") if err != nil { return nil, fmt.Errorf("failed to query user: %v", err) } There's an inherent asymmetry between how often those three conditional lines are executed relative to the undeniable fact that error handling is three times the code line volume versus the core business logic. That's not ok; and when I look at the argument phrased like that I find it hard to believe that anyone reasonable can take the stance that its desirable that error handling requires writing substantially more code than The Thing Which Generated The Error In The First Place.

svnpenn 4y ago
> There's an inherent asymmetry No there's not. People seem to just want to ignore all errors, and let the language "figure it out", AKA exceptions. If you want to ignore errors, then just go all the way and do that: result, _ := db.GetUser("12345") then, you never have to worry about errors, you can just code in bliss and wait for the "panic" because you didn't want to bother with proper error handling.
- peterashford 4y ago
  That really misrepresents how exceptions are used, IMO.
  - sidlls 4y ago
    Depends on the code base, as usual, and the quality of the development practices the code was written in. Same as go's error handling, actually.
- xigoi 4y ago
  With exceptions, you can handle the error in the place that can handle it. That's not the case with your example.
- bheadmaster 4y ago
  Actually, your example would continue running the happy path as if the error didn't happen, returning erroneous results, but not panicking: func main() { x, _ := getNonZero() fmt.Println("Nonzero number:", x) } func getNonZero() (int, error) { return 0, errors.New("oops") } The "_" is supposed to be used only when you're absolutely sure that error cannot happen (e.g. the function you're calling is partial, but you know that the input is in the defined set).
Arbortheus 4y ago
I disagree, I think that handling the failure cases properly is much more complex and requires more consideration than the success cases. Sure, in many cases you’re going to bubble up the error (perhaps a syntactic sugar for this scenario would help), but there are lots of production error handling considerations like transaction rollbacks, response statuses, logging, metrics, opentelemetry traces, retry logic, that you will need to handle in practice, and you will want to handle these differently in different failure modes. Ensuring software acts in an expected way in the transient 0.001% scenarios is very important. With Go I never run into unhandled exceptions causing software to blow up like I do with large Python codebases. At first I didn’t like the “if err != nil” bloat of Go code, but now I appreciate its explicitness, it is distinctly unmagical, simple, boring, and works well in production.
- 015a 4y ago
  This isn't a situation where the choices are: 3 lines of IDE-Insert-Boilerplate, or Exceptions. I think Go could add syntax to keep its relatively unique form of error handling, while reducing code noise. The guard proposal is fine, but I'd prefer to see something like: func MyFunc() error { r := db.Get("12345") guard "error Get(12345)" } Syntactically really strange, but point being: if a function returns (any, ..., error); 'guard' is a keyword which eats the last 'error', optionally prefixes it with the string in that last keyword argument (standard golang error wrapping: "error Get(12345): {err.Error()}", and bubbles it up (along with zero or default values for the other arguments). It would also be nice, for more complex use-cases, if that last argument could be a mapping function as well, like: func MyFunc() CustomError { r := db.Get("12345") guard func(err error) CustomError { return CustomError{baseErr: err, code: 500} } } Though, I'd gladly settle to not have that, as it goes a little beyond the extreme syntactic simplicity I expect out of go.
klodolph 4y ago
> [...] I find it hard to believe that anyone reasonable can take the stance that its desirable that error handling requires writing substantially more code than The Thing Which Generated The Error In The First Place. I have personal experience with Java, Go, and C#, to varying degrees. Over the years, my personal style has changed a lot, based on my experience running applications (as someone in ops), developing applications, debugging applications, etc. First of all, I'll say that doing Go error handling well figuring out the right place to add context to your errors. So in the example above: return nil, fmt.Errorf("failed to query user: %v", err) The error is from a method named "GetUser", and in the style guide I use, errors from GetUser would already say something like "get user %d: %w". You'd know this when writing code that calls GetUser, and wouldn't double-wrap it with additional context, if the additional context is not useful. That's a bit of a tangent. My experience working in operations is that errors in languages like Java are often stack traces. The stack traces are often large and often have poor signal-noise. Important context is often missing--things like arguments to methods. C++ is sometimes worse, since there's a lot of C++ code out there which won't even give you a stack trace. Worst of all worlds, perhaps. As I've gotten older, I've moved to a very proactive style of error checking. This style is verbose in all languages, and sometimes this style is much more natural in Go. That's because of the number of times that putting effort into error checking has saved my butt when debugging. By the time I'm debugging a piece of code, it might long forgotten. The error might be hard to reproduce. Getting a good report the first time saves a ton of time when debugging. In other languages, this might be accomplished by aggressive logging, or tools like time travel debugging, or catch & rethrow. My sense of Go's error handling is that it is a lot of code only if you measure it by line count. The error handling is very boilerplate and you stop seeing it, like when Cypher's looking at code in The Matrix. https://www.youtube.com/watch?v=MvEXkd3O2ow https://www.youtube.com/watch?v=MvEXkd3O2ow In isolated cases, it makes sense to panic() / recover() in Go. People new to Go sometimes overuse panic(), and then once they get more experience they overcompensate and don't ever panic()... I think there's a middle ground here, where panic()/recover() is useful in certain situations. I use it most for parsing / marshaling / unmarshaling code. Parsers, for example, can be very dense, and the error handling is often just "return to top, throw everything away, no additional context to report". What we need is some education like "case studies for when you might want to panic/recover in Go" or "case studies in where you should add context to error messages".
Gibbon1 4y ago
I've sometime wonder about passing a label for error handling result, err := db.GetUser("12345": no_user) no_user: return nil, fmt.Errorf("failed to query user: %v", err) If there is an error the program jumps to the label. If no label the program panics. This implied that you have both return and return_error keywords.
IshKebab 4y ago
> error handling is three times the code line volume versus the core business logic. That's not ok It is ok. That's really how it should be IMO. The "problem" is that Go doesn't allow you to say "eh, we'll just give a stack trace to the user, and then they can delete it print Oops something went wrong" which is apparently what most people want from their error handling.

by 015a 4y ago

svnpenn 4y ago

> There's an inherent asymmetry No there's not. People seem to just want to ignore all errors, and let the language "figure it out", AKA exceptions. If you want to ignore errors, then just go all the way and do that: result, _ := db.GetUser("12345") then, you never have to worry about errors, you can just code in bliss and wait for the "panic" because you didn't want to bother with proper error handling.

peterashford 4y ago
That really misrepresents how exceptions are used, IMO.
- sidlls 4y ago
  Depends on the code base, as usual, and the quality of the development practices the code was written in. Same as go's error handling, actually.
xigoi 4y ago
With exceptions, you can handle the error in the place that can handle it. That's not the case with your example.
bheadmaster 4y ago
Actually, your example would continue running the happy path as if the error didn't happen, returning erroneous results, but not panicking: func main() { x, _ := getNonZero() fmt.Println("Nonzero number:", x) } func getNonZero() (int, error) { return 0, errors.New("oops") } The "_" is supposed to be used only when you're absolutely sure that error cannot happen (e.g. the function you're calling is partial, but you know that the input is in the defined set).

Arbortheus 4y ago

I disagree, I think that handling the failure cases properly is much more complex and requires more consideration than the success cases. Sure, in many cases you’re going to bubble up the error (perhaps a syntactic sugar for this scenario would help), but there are lots of production error handling considerations like transaction rollbacks, response statuses, logging, metrics, opentelemetry traces, retry logic, that you will need to handle in practice, and you will want to handle these differently in different failure modes. Ensuring software acts in an expected way in the transient 0.001% scenarios is very important. With Go I never run into unhandled exceptions causing software to blow up like I do with large Python codebases. At first I didn’t like the “if err != nil” bloat of Go code, but now I appreciate its explicitness, it is distinctly unmagical, simple, boring, and works well in production.

015a 4y ago
This isn't a situation where the choices are: 3 lines of IDE-Insert-Boilerplate, or Exceptions. I think Go could add syntax to keep its relatively unique form of error handling, while reducing code noise. The guard proposal is fine, but I'd prefer to see something like: func MyFunc() error { r := db.Get("12345") guard "error Get(12345)" } Syntactically really strange, but point being: if a function returns (any, ..., error); 'guard' is a keyword which eats the last 'error', optionally prefixes it with the string in that last keyword argument (standard golang error wrapping: "error Get(12345): {err.Error()}", and bubbles it up (along with zero or default values for the other arguments). It would also be nice, for more complex use-cases, if that last argument could be a mapping function as well, like: func MyFunc() CustomError { r := db.Get("12345") guard func(err error) CustomError { return CustomError{baseErr: err, code: 500} } } Though, I'd gladly settle to not have that, as it goes a little beyond the extreme syntactic simplicity I expect out of go.

klodolph 4y ago

> [...] I find it hard to believe that anyone reasonable can take the stance that its desirable that error handling requires writing substantially more code than The Thing Which Generated The Error In The First Place. I have personal experience with Java, Go, and C#, to varying degrees. Over the years, my personal style has changed a lot, based on my experience running applications (as someone in ops), developing applications, debugging applications, etc. First of all, I'll say that doing Go error handling well figuring out the right place to add context to your errors. So in the example above: return nil, fmt.Errorf("failed to query user: %v", err) The error is from a method named "GetUser", and in the style guide I use, errors from GetUser would already say something like "get user %d: %w". You'd know this when writing code that calls GetUser, and wouldn't double-wrap it with additional context, if the additional context is not useful. That's a bit of a tangent. My experience working in operations is that errors in languages like Java are often stack traces. The stack traces are often large and often have poor signal-noise. Important context is often missing--things like arguments to methods. C++ is sometimes worse, since there's a lot of C++ code out there which won't even give you a stack trace. Worst of all worlds, perhaps. As I've gotten older, I've moved to a very proactive style of error checking. This style is verbose in all languages, and sometimes this style is much more natural in Go. That's because of the number of times that putting effort into error checking has saved my butt when debugging. By the time I'm debugging a piece of code, it might long forgotten. The error might be hard to reproduce. Getting a good report the first time saves a ton of time when debugging. In other languages, this might be accomplished by aggressive logging, or tools like time travel debugging, or catch & rethrow. My sense of Go's error handling is that it is a lot of code only if you measure it by line count. The error handling is very boilerplate and you stop seeing it, like when Cypher's looking at code in The Matrix. https://www.youtube.com/watch?v=MvEXkd3O2ow https://www.youtube.com/watch?v=MvEXkd3O2ow In isolated cases, it makes sense to panic() / recover() in Go. People new to Go sometimes overuse panic(), and then once they get more experience they overcompensate and don't ever panic()... I think there's a middle ground here, where panic()/recover() is useful in certain situations. I use it most for parsing / marshaling / unmarshaling code. Parsers, for example, can be very dense, and the error handling is often just "return to top, throw everything away, no additional context to report". What we need is some education like "case studies for when you might want to panic/recover in Go" or "case studies in where you should add context to error messages".

Gibbon1 4y ago

I've sometime wonder about passing a label for error handling result, err := db.GetUser("12345": no_user) no_user: return nil, fmt.Errorf("failed to query user: %v", err) If there is an error the program jumps to the label. If no label the program panics. This implied that you have both return and return_error keywords.

IshKebab 4y ago

> error handling is three times the code line volume versus the core business logic. That's not ok It is ok. That's really how it should be IMO. The "problem" is that Go doesn't allow you to say "eh, we'll just give a stack trace to the user, and then they can delete it print Oops something went wrong" which is apparently what most people want from their error handling.