Errors are different in every stdlib or 3rd party package I've ever used.

The ecosystem as a whole decided that errors should be useful, values, and properly bubbled up - and that your application should not be so hard to reason about that you need a stack trace to know where in the deep recesses of your code something went wrong.

I love stack traces in Java, but I don't miss them at all in Go.

Sounds a bit apologetic. I don't think that the ecosystem decided. The language creators decided, and the ecosystem couldn't do much about it.

Go's development process is fairly open and democratic though; if enough people flag it up, and if a case can be made for stack traces, it can be added.

As it stands though, the consensus is that it doesn't add enough value, it's too expensive (cost/benefit), errors are normal program flow, and 3rd party libraries can add the functionality if one decides they need/want it in their application.

I say ecosystem to mean the majority of packages. That's the ecosystem.

"your application should not be so hard to reason about that you need a stack trace to know where in the deep recesses of your code something went wrong."

Curious how Go is better than other languages in this regard.

That quote isn't about Go specifically though, but about general application design. It seems to be a subtle snipe that languages with stacktraces like Java, C# are too complicated or have too many layers ("lasagna code"), making them more difficult to debug.

we wrap all errors with a stack.Wrap function that adds stacktrace to the error. This allows us to add stacktraces to logs and err reporting tools like Sentry. Huge time saver

You can do it yourself if you want using `runtime.Stack` and a custom error type

Embarrassingly, I’ve been writing Go for a while but never really thought about it. Now that it’s been mentioned I’m curious why this isn’t baked in by default for errors. Does anyone know?

You’re supposed to prepend the context to an error before you return it, so the final error reads like a top-level stack trace: “handling request: fooing the bar: barring the baz: connecting to DB: timeout.”

Well, how would that work?

Errors are just values. They don't have any special meaning nor is there any special ceremony to create them. A panic must start from calling panic(); there's no function or special statement to create or return an error.

It might be possible to augment every `error`-typed return such that the concrete type is replaced by some synthetic type with a stack trace included. However, this would only work because `error` is an interface, so any function returning a concrete-typed error wouldn't be eligible for this; it would also add a lot of runtime overhead (including, at the very least, a check for nil on every return); and it would cause issues with code that still does == comparisons on errors.

On the whole, I think error-wrapping solves the problem of tracing an error well enough as the language exists today. If errors are going to start having some magic added to them, I think the entirety of error-handling deserves a rethink (which may be due, to be fair).

> I’ve been writing Go for a while but never really thought about it.

Don't feel bad, I've tried to do this in some places, but I'm not sure it's worth it. It adds a ton of boilerplate to Go's already verbose error handling, since you need to wrap every error that gets returned from libraries.

Creating stack traces is expensive.

you only do it when there is a not nil err + being able to have a stacktrace is worth more than whatever it costs is CPU

Good error-wrapping discipline works better than stack traces, because not only do you have a trace of the calling context, you also have the values that caused the problem. Granted, a stack trace "always works", but it will never have the values of important variables.

Now you mention it, a stack trace with function calls and all their arguments would be really powerful. But also expensive, ideally it would have zero overhead or only have the cost if you actually look at it / want to debug it.

One of the major optimizations is to pass function arguments in registers instead of on the stack. These registers might preserve their original values by the time you unwind the stack, but in many cases, probably won't. Preserving those values would lead to fewer available registers and/or more frequent register saving, which would create at least some overhead, even if you don't ever inspect it.

There are probably lots of situations where it's worth it, though.

We do both and it works great

That's still under the assumption that errors are exceptional, rare, and require a stacktrace to debug. But most errors are not exceptional and do not need debugging, like idk, a row not found error in a database.

A crash, sure, that might need a stacktrace to debug. But that's already in place.