You're kind of building a stack of exceptional cases... Wonder what that is :D
What canceled my Go context?
31–40 of 70 posts
Re: What canceled my Go context?
#32It’s great that they identified this (incredibly common) pain point and introduced a way to solve it, but I can’t help being disappointed. 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 t…
> 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.
The rule of thumb is to wrap always.
Re: What canceled my Go context?
#33It’s great that they identified this (incredibly common) pain point and introduced a way to solve it, but I can’t help being disappointed. 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 t…
I agree go’s error handling feels a bit clunky, though I prefer the local error handling and passing up the chain (if it were a bit more ergonomic) to exceptions, which IMO have a lot of other problems. 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 us…
In an HTTP server, top level means the handlers, is that so?
Re: What canceled my Go context?
#34It’s great that they identified this (incredibly common) pain point and introduced a way to solve it, but I can’t help being disappointed. 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 t…
> 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. The rule of thumb is to wrap always.
Then it results in an absurd amount of duplication. I regularly encounter error strings like:
error:something happened:error:something happened
Re: What canceled my Go context?
#35Earlier quoted context omitted.
Author here. I absolutely hated writing this piece after shooting myself in the foot a thousand times. Go's context ergonomics is kinda terrible and currently there's no way around it.
It was a great piece and I learned a lot, thanks for writing it. I hope you didn’t think that it was you I was disappointed with rather than the language designers :) 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…
No worries. Your intent was clear. I don't mind the boilerplates if they were footgun free. Context requires you write a bunch of boilerplate where it's still really easy to make mistakes.
Re: What canceled my Go context?
#36Le sigh. "I don't wrap errors and so I don't know where my errors come from."
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
}
Re: What canceled my Go context?
#37Earlier quoted context omitted.
> 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. The rule of thumb is to wrap always.
Then it results in an absurd amount of duplication. I regularly encounter error strings like: error:something happened:error:something happened
Yes, and that is desired.
Error: failed processing order: account history load failure: getUser error: context deadline exeeded
Re: What canceled my Go context?
#38Golang returning tuples but not having pattern matching is something I'll never get. I really feel it's a too dumbed down version of erlang/elixir, especially with this context passing business
Re: What canceled my Go context?
#39Earlier quoted context omitted.
Then it results in an absurd amount of duplication. I regularly encounter error strings like: error:something happened:error:something happened
Yes, and that is desired. Error: failed processing order: account history load failure: getUser error: context deadline exeeded
Your example shows an ideal case w/o repetition. If every layer just wraps error without inspecting, then there will be duplication in the error string.
Re: What canceled my Go context?
#40Earlier quoted context omitted.
Yes, and that is desired. Error: failed processing order: account history load failure: getUser error: context deadline exeeded
Your example shows an ideal case w/o repetition. If every layer just wraps error without inspecting, then there will be duplication in the error string.
I have never seen that. I have shipped multiple dozens of services at half a dozen companies. Big code bases. Large teams. Large volumes of calls and data. Complicated distributed systems.
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.