4 ms·
Go's boilerplate if err != nil return err, nil becomes something that your eyes just skim over OTOH, if you make sure you do something like if err != nil
by kitd 3y ago
Go's boilerplate if err != nil return err, nil becomes something that your eyes just skim over
OTOH, if you make sure you do something like
if err != nil {
return fmt.Errorf("what I was doing when the error happened: %v", err)
}
then you get very precise targeted errors appearing in logs that are much easier to track down and fix than either just returning the error or the usual generic catch block found in other languages.
IME properly handled Go errors make for much more maintainable code.
- kaba0 3y agoMaybe even include a stacktrace, and you got what any sane language with exceptions had for decades, hurray again for Go!
- kitd 3y agoThe problem (as alluded to above) is that stacktraces give you no context to what went wrong, only where it happened and the (possibly cryptic) underlying error. IMO the real value in proper error handling (ie what makes fixing errors easy) is that context, not the precise line # of the error which, though useful, is supplementary data. Rust errors with anyhow::Contexts are far more workable than those without. Edit: I actually wrote a simple Result handling package for Go that includes error context and stacktraces: https://github.com/kitd/chock https://github.com/kitd/chock
- kaba0 3y agoThat’s why you throw an exception, catch it some level up, and rethrow it wrapped in another exception, with proper context.
- kitd 3y agoI think we're arriving at the same solution, with approximately the same amount of boilerplate if done to same degree of accuracy.
- marcus_holmes 3y agoExcept no-one does this in practice. There's a half-assed exception handler at the top level that catches everything and that's all. At least in most of the code bases I've seen. Go encourages you to handle the error at the point of calling, which is good.
- kaba0 3y agoIt’s still better than swallowing an error.
- lmm 3y agoBut in practice people don't do that in Go either, they just add a bunch of if error != nil lines, so you end up with no more information about what went wrong (in fact less information than you'd get with an exception, since you don't even get a stack trace) and just have more clutter in your code.
- kitd 3y agoIt's not the `if err != nil` that's the problem, it's the following `return nil`. As I mention above, return instead the error with some identifying information and context, and you get highly targeted details needed to locate and fix the problem. And the way Go handles this makes it simpler than doing it via exception handling.
- closeparen 3y agoExcept in languages other than Go you’re usually in some kind of async system that renders stacktraces useless.
- burnished 3y agoStrong agree. Stack traces are great and all (seriously) but a chain of contextual error messages in developer friendly language is great for understanding what probably went wrong from the error alone.