Right so; the way it was written implied that at least they had spent significant amount of time on it, at least to me (I tried a quick grep in "git log" to see if I could find them, but couldn't find anyone matching the username here).
They were always on, used them as power monitors. One on my washing machine, one on the 3d printer, one on the tumble dryer. One on and off depending on the season, christmas tree and similar.. They all died the same way, at some point never turned on again without any apparent reason.
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.”
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.
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.
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.
