maybe you do, but I prefer an error chain that was designed. A Go program rarely has just one stack, because every goroutine is its own stack. Having the trace of just that one stack isn’t really a statement of the program as a whole since there’s many stacks, not one. Additionally, stack traces omit the parameters to the functions at each frame, which means that understanding the error means starting with your stack trace, and then bouncing all over your code and reading the code and running it in your head in order to understand your stack trace. This is even more annoying if you’re looking at an error several days later in a heterogeneous environment where you may need the additional complication of having to figure out which version of the code was running when that trace originated. Or you could just have an error like “failed to create a room: unable to reserve room in database ‘database-name’: request timed out” or something similar. Additionally, hand-crafted error chains have the effect that they are often much easier to understand for people who operate but don’t author something; they may have never seen the code before, so understanding what a stack trace means exactly may be difficult for them, especially if they’re not familiar with the language.

FWIW, I wrote a helper that adds tracing information.

I sort of have two minds about this. On the one hand, yeah, computers are good at tracking stack traces, why are we adding them manually and sporadically? OTOH, it’s nice that you can decide if you want the traces or not and it gives you the ability to do higher level things like using errors as response codes and whatnot.

The thing that I have read about in Zig that I wish Go had is an error trace which is different from the stack trace, which shows how the error was created, not the how the error propagates back to the execution error boundary which is not very interesting in most scenarios.

In a multiprocess system that’s exchanging messages: which stack?

You don’t want stack traces; you want to know what went wrong.

A stack trace can suggest what may have gone wrong, but an error message that declares exactly what went wrong is far more valuable, no?

Stack traces are expensive to compute and inappropriate to display to most users. Also, errors aren’t exceptions.

What really is the “origin” of an error? Isn’t that somewhat arbitrary? If the error comes from a system call, isn’t the origin deeper in the kernel somewhere? What if you call in to a remote, 3rd party service. Do you want the client to get the stack trace with references to the service’s private code? If you’re using an interface, presumably the purpose is to abstract over the specific implementation. Maybe the stack trace should be truncated at the boundary like a kernel call or API call?

Stack traces are inherently an encapsulation violation. They can be useful for debugging your internals, but they are an anti-feature for your users debugging their own system. If your user sees a stack trace, that means your program is bugged, not theirs.

Lots of pundits say lots of stuff. One good way to learn good patterns (I won’t call them “right”), is to look at real code by experienced Go developers. For instance, if you look at https://github.com/tailscale/tailscale you’ll find pervasive use of fmt.Errorf. One thing you might not see – at least not without careful study – is how to handle code with lots of error paths. That is by it’s very nature harder to see because you have to read and understand what the code is trying to do and what has to happen when something goes wrong in that specific situation.

there is a right way to do most things; but it takes some context and understanding for why.

the mistake is thinking go is approachable for beginners; it’s not.

go is an ergonomic joy for people that spend a lot of time investing in it, or bring a ton of context from other languages.

for beginners with little context, it is definitely a mess.

That uses the non-standard errors package and has been obsolete since 1.13: https://stackoverflow.com/questions/61933650/whats-the-difference-between-errors-wrapf-errors-errorf-and-fmt-errorf

return fmt.Errorf("fooing %s %w", bar, err) is idiomatic.

You can use errors.Is to check wrapped errors - https://pkg.go.dev/errors#Is

Is unwraps its first argument sequentially looking for an error that matches the second. It reports whether it finds a match. It should be used in preference to simple equality checks

Yes, but you can use errors.Is and errors.As to solve that problem. These use errors.Unwrap under the hood. This error chaining mechanism was introduced in Go 1.13 after being incubated in the “errors” package for a long while before that. See https://go.dev/blog/go1.13-errors for details.

I agree.

But Go, eg, is not Haskell, and that’s an explicit language design decision. I think Haskell is a more beautiful language than Go, but Go has its reasons for not wanting to go that direction – Go values simple verbosity over more abstract elegance.

This might not be that convincing / intelligible, but it’s the code I was thinking of:

https://github.com/oilshell/oil/blob/master/osh/word_eval.py#L1332

Basically vsub_state is an “out param” that is mutated, but there’s also a return value val.

This is for evaluating:

• $foo and "$@" – “simple var sub”
• ${foo} and ${@} – “braced var sub”
• as well as “var refs” like ${!a} where the value is @, which is yet another way to get $@

So all of those return a “val”. It is like a typical interpreter that does a switch/match over dozens of cases and returns a different value based on the sum type.

But then only in minority of cases do you have to convert an array to a string – this is weird shell behavior.

The out param means you don’t have to “pollute” every code path with that logic; instead I just mutate the out param in the one place I need to. AND sometimes you pass the out param down TWO levels instead of one.

And it composes well – I can use it from 3 different contexts.

This is pretty deep inside baseball, but I did actually refactor it from a different style, and this ended up cleaner, shorter, and more composable. It probably looks pretty confusing without detailed knowledge of the problem domain, but I think reading the signatures of the functions now clarifies a lot of things.

I don’t think this style applies everywhere – sum types and exceptions are more common. But when I saw the Go code with 2 return values I can definitely see it being cleaner, roughly like

T1 x;
if (!func1(&x) {  // x is output param, return value is success/fail
  return false;
}

T2 y;
if (!func2(x, &y)) {  // x is input, y is output
  return false;
}

T3 z;
 if (!func3(y, &z)) {  // y is input, z is ouput
   return false;
 }
 return true;  // success, output can be read from z "out param"

This is basically func3(func2(func1())) but with (non-exception) error handling (in C++ syntax).

And limiting variable names to just “x”, “y” and “z” are also simpler and much less ceremony than typing out full variable names

It’s bad because changing the visibility of a member requires renaming it, which requires finding and updating every caller. This is an annoying manual task if your editor doesn’t do automatic refactoring, and it pollutes patches with many tiny one-character diffs.

It reminds me of old versions of Fortran where variables that started with I, J, K L or M were automatically integers and the rest were real. 🙄

The author of the submitted article wrote a sequel article, Go’ing Insane Part Two: Partial Privacy. It includes a section Privacy via Capitalisation that details what they find frustrating about the feature.

Sure, but I would not exactly call splitting it up hard and in Go you could if you really have the case a lot handle errors just like that. It’s easy to write such a wrapper if it bothers you much.

In addition looking into real projects I have seen it more than once where that pattern was used a lot and the assumption that you can/want to handle all errors the same way either was wrong or became wrong.

Depending on the language you might easily catch too much (JavaScript being a great example here) or you especially if logging or similar would happen you usually end up wanting to have more context with your error anyways.

Of course it depends on what exactly you are doing, but at least in my experience splitting try/catch up seems to be something I do more frequently than combing error handling.

That’s also a bit of what I mean with choosing another language. But it’s also really about project sizes. If you have a bigger project you might add helpers to do what makes sense for a project anyways, maybe doing something with the errors/exceptions so you end up extracting that error value from the catch block and essentially end up the same as in Go after that helper function.

Of course for tiny let’s say “scripts” that might be a lot but if it’s really a tiny thing I think in many cases people completely ignore error handling.

Don’t get me wrong though. Of course there’s a reason try catch exists, but what gets me is when people choose a language that does a few things differently and then complain about that language having a faulty, quirky design because it is not pretty much exactly like hundreds of other languages. It’s a valid design decision to keep the language simple by treating errors like just another value/type and interact with via all the same means as all the others variables you have.

If someone programs in Go,or any other language and it’s unhappy about it not being Java (or any other language) why not use Java (or any other language)?

It’s not like you have to use Go, cause it’s by some people currently employed by Google or something.

And I know that there’s situations where for one reason or another you have to hat a certain language, but honestly that’s just part of the job and often you can get around it. It’s just ranting about language specifics and being like “they are doing it wrong” mostly cause they are doing it differently from your language of taste feels like something going nowhere. I mean it’s also not like nobody ever thought of doing try,/catch and I’m pretty sure that some of the Go core team developers would not only know about try/catch but eben have the knowledge to implement it if they wanted.

So what’s the point in being the millionth or so person to say they prefer try/catch over Go’s way?

There’s other languages, some of them sharing other things with Go. LLVM spawned huge amounts of languages in addition to huge amount of other languages. Wouldn’t time be better spent writing whatever you are missing there and be happy and productive instead of just repeating dislike and calling other designs “quirks”?

Unless that’s your hobby and what your want to be doing of course. Just feels a bit redudant on lobster.rs