3 ms·

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 y

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.

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.