> lemoncucumber
> it can be tempting to keep adding layer upon layer of wrapping resulting in an unwieldy error string that’s practically a hand-rolled stacktrace
I thought this was the whole reason to wrap errors, to know where they passed up the chain.
Funny how it seems no matter the subject, if Go is involved, errors get discussed.
Is there any equivalent in major popular languages like Python, Java, or JS of this?
Example:
maybeVal <— timeout 1000000 myFunction
In Haskell, cancellability is the default and carries no syntax overhead.
This is one of the reasons why I think Haskell is currently the best language for writing IO programs.
(I also think there's some wonkiness with and barriers to understanding Python's implementation that I don't think plagues Go to quite the same extent.)
https://github.com/ggoodman/context provides nice helpers that brings the DX a bit closer to Go.
Also, a sibling poster mentioned ZIO/Scala which does the Structured Concurrency thing out of the box.
The contexts and errors communicate information in different directions. Errors let upstream function know what happened within the call, context lets downstream functions know what happened elsewhere in the system. As a consequence there isn't much point to cancel the context and return the error right away if there isn't anybody else listening to it.
Also, context can be chained by definition. If you need to be able to cancel the context with a cause or cancel it with a timeout, you can just make two context and use them.
Example that shows the approach as well as the specific issue raised by the post: https://go.dev/play/p/rpmqWJFQE05
Thanks for the post though! Made me think about contexts usage more
The code that justifies the special context handling:
if err := chargePayment(ctx, orderID); err != nil {
cancel(fmt.Errorf(
"order %s: payment failed: %w", orderID, err,
))
return err
}
Reading the examples I found myself thinking, “that looks like a really useful pattern, I should bookmark this so I can adopt it whenever I write code like that.”
The fact that I’m considering bookmarking a blog post about complex boilerplate that I would want to use 100% of the times when it’s applicable is a huge red flag and is exactly why people complain about Go.
It feels like you’re constantly fighting the language: having to add error handling boilerplate everywhere and having to pass contexts everywhere (more boilerplate). This is the intersection of those two annoyances so it feels especially annoying (particularly given the nuances/footguns the author describes).
They say the point is that Go forces you to handle errors but 99% of the time that means just returning the error after possibly wrapping it. After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.
I hope someday they make another attempt at a Go 2.0.
The main problems seem to me to be boilerplate and error types being so simplistic (interface just has a method returning a string). Boilerplate definitely seems solvable and a proper error interface too. I tend to use my own error type where I want more info (as in networking errors) but wish Go had an interface with at least error codes that everyone used and was used in the stdlib.
My rule of thumb on annotation is default to no, and add it at the top level. You’ll soon realise if you need more.
How would you fix it if given the chance?
Depends if it can be handled lower (with a retry or default data for example), if it can be it won’t be passed all the way up.
Generally though I haven’t personally found it useful to always annotate at every point in the call chain. So my default is not to annotate and if err return err.
What I like about errors instead of exceptions is they are boring and predictable and in the call signature so I wouldn’t want to lose that.
It should be the same handling as all other types. If it feels clunkier than any other type, you've not found a good design yet. Keep trying new ideas.
1. if err != nil is verbose and distracting and happens a lot. I'd prefer say Ian Lance Taylor's suggestion of something like this where you're just going to return it vs standard boilerplate which has to return other stuff along with the error:
// ? Returns error if non-nil, otherwise continue
data, err := os.ReadFile(path) ?
// Current situation
data, err := os.ReadFile(path)
if err != nil {
}The second is a problem of culture more than anything but the stdlib is to blame:
2. The errors pkg and error interface has very basic string-based errors. This is used throughout the stdlib and of course in a lot of go code so we are forced to interact with it. It also encourages people to string match on errors to identify them etc etc. Yes you can use your own error types and error interfaces but this then creates interop problems and inevitably many pkgs you use return the error interface. I use my own error types, but still have to use error a lot due to stdlib etc. The wrapping they added and the annotation they encourage is also pretty horrible IMO, returning a bunch of concatted strings.
So these are not things that end users of the language can fix. Surely we can do better than this for error handling?
if err != nil is no more or less verbose than if x > y. You may have a point that Go could do branching better in general, but that isn't about errors specifically.
If there is something about errors that happening a lot then that still questions your design. Keep trying new ideas until it isn't happening a lot.
> Surely we can do better than this for error handling?
Surely we can do better for handling of all types? And in theory we can. In practice, it is like the story of generics in Go: Nobody smart enough to figure out a good solution wants to put in the work. Google eventually found a domain expert in generics to bring in as a contractor to come up with a design, but, even assuming Google is still willing to invest a lot of money in the new budget-tightening tech landscape, it is not clear who that person is in this case.
Ian Lance Taylor, as you mention, tried quite hard — with work spanning over many years — in both in both cases to find a solution, which we should commend him for, but that type of design isn't really his primary wheelhouse.
The community is special and now with the original authors mostly gone, and AI into the mix, I don't see it ever happen.
We will get ridiculous Go 1.xyzabc version numbers.
Java, C# and so on are scripting languages that compile to bytecode that's then run by a painfully slow interpreter.
The rule of thumb is to wrap always.
error:something happened:error:something happened
do c: edit b: create a: something happened
For functions called doC, editB, createA.
It’s like a stack trace and super easy to find the codepath something took.
I have never had difficulty quickly finding the error given only the top two stack sites.
Any complaint about go boilerplate is flawed. The purpose and value is not in reducing code written, it is to make code easier to read and it achieves this goal better than any other language.
This value is compounding with coding agents.
Error: failed processing order: account history load failure: getUser error: context deadline exeeded
I am unable to imagine a case where an error string repeated itself. On a loop, an error could repeat, but those show as a numerical count value or as separate logs.
Typically there is only one possible code path if you can identify both ends.
Do1:...Do10, which then DoX,DoY,DoZ and one of those last 3 failed.
Do you really need Do1 to Do10 to be annotated to know that DoY failed when called from Do1? I find:
Do1:DoZ failed for reason bar
Just as useful and a lot shorter than: Do1: failed:Do2:failed...Do9 failed:Do10:failed:DoZ failed for reason bar
It is effectively a stack trace stored in strings, why not just embed a proper stack trace to all your errors if that is what you want?
Your concern with having a stack trace of calls seems a hypothetical concern to me but perhaps we just work on different kinds of software. I think though you should allow that for some people annotating each error just isn't that useful, even if it is useful for you.
Go's context ergonomics is kinda terrible and currently there's no way around it.
It’s ironic how context cancellation has the opposite problem as error handling.
With errors they force you to handle every error explicitly which results in people adding unnecessary contextual information: it can be tempting to keep adding layer upon layer of wrapping resulting in an unwieldy error string that’s practically a hand-rolled stacktrace.
With context cancellation OTOH you have to go out of your way to add contextual info at all, and even then it’s not as simple as just using the new machinery because as your piece demonstrates it doesn’t all work well together so you have to go even further out of your way and roll your own timeout-based cancellation. Absurd.
I need to start getting used to context with cancel cause - muscle memory hasn't changed yet.
Just pass along two hidden variables for both in parameters and returns, and would anything really change that the compiler wouldn't be able to follow?
i.e. most functions return errors, so there should always be an implicit error return possible even if I don't use it. Let the compiler figure out if it needs to generate code for it.
And same story for contexts: why shouldn't a Go program be a giant context tree? If a branch genuinely doesn't ever use it, the compiler should be able to just knock the code out.
The same would apply to anytime you have Result types - ultimately its still just syntactic sugar over "if err then...".
What's far more common in real programs is that an error can occur somewhere where you do not have enough context to handle or resolve it, or you're unaware it can happen. In which case the concept of exceptions is much more valid: "if <bad thing here> what do I want to do?" usually only has a couple of places you care about the answer (i.e. "bad thing happened during business process, so start unwinding that process" and many more where the answer is either "crash" or "log it and move on to the next item".
The problems are that the signature of functions doesn’t say anything about what values it might throw, and that sometimes the control flow is obscured — an innocuous call throws.
Both of these are solvable.
My argument here would be, that all of this though doesn't need to be seen unless its relevant - it seems reasonable that the programmer should be able to write code for the happy path, implicitly understanding there's an error path they should be aware of because errors always happen (I mean, you can straight up run out of memory almost anywhere, for example).
They would rather not solve it, thinking that the "programmers will deal with it".
Now they claim it’s too late.
I disagree. I feel like I constantly understand precisely what the language is and is not going to do. This is more valuable to me than languages with 100 sigils that all invoke some kind of "magic path" through my code.
> forces you to handle errors but 99% of the time that means just returning the error after possibly wrapping it
How do you universally handle an inventory error? The _path_ to and from the error is more important than the error or it's handling clauses.
> After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.
Isn't the point of the above that no matter which you choose the code is mostly the same? How much of an impact is this to refactor when you change your mind? For me it's almost zero. That right there is why I use go.
When writing your tests:
1. Ensure all error cases are identifiable to the caller — i.e. using errors.Is/errors.AsType
2. Ensure that you are not leaking the errors from another package — you might change the underlying package later, so you don't want someone to come to depend on it
As long as those are satisfied, it doesn't matter how it is implemented.
I quite enjoy C# and F# and while they are low boiler plate, you can really learn them in a week or two the way you can learn Go.
And even you don't know anything about Go, you can literally jump into the code base and understand and follow the flow with ease - which quite amazes me.
So unfortunately, every language has trade offs and Go is not an exception.
I can't say I enjoy Go as a language but I find it very, very useful.
And since many people are using LLMs for coding these days, the boiler plate is not as much an issue since it be automated away. And I rather read code generated in Go than some C++ cryptic code.