IIRC, that's why Go errors don't come with stack traces by default, performance.

I'll admit that this has enraged me on a few occasions when all I have to work with is a logged error message of

   strconv.ParseInt: parsing "": invalid syntax

With no clues as to where the hell the error actually happened, so I have to start grepping the app's code, then the code of its dependencies, then the code of the dependencies' dependencies.

A stack trace would be helpful, but so would adding context to the error (when appropriate), instead of just bubbling it up indiscriminately.

Of course, you can’t enforce this is dependencies, but at least tracking this to the first layer dependencies of your code should be fairly easy right?

TBH, Go style errors seem more flexible if some care is put into using them, however they are extremely unhelpful if they are used improperly (even if it’s not your own code).

I agree very much. This was ultimately an ORM trying to convert a NULL to an int. An error message like "I was trying to load EntityX and got this error" would've been ideal.

It's a reasonably common issue with running Go apps, you're relying on the coder to make good decisions to give you useful insights.

Other ecosystems I've used err more in favour of the person running the thing - compare the more widespread Go logging libs to, say, Java, where the sysop has very fine-grained control if they need it.

This is another reason why Common Lisp style condition system (where exception handlers can execute without unwinding the stack) just seems to work better. If you need the stack, get the stack, if you don't then just use handler-case. I really don't see the downside for any language that has anonymous function literals.

CL condition system is based on error handlers, which is the 3rd paradigm aside from returning error values and exceptions. Unfortunately, it didn't really permeate the Unix based languages (C, C++, Java), because Unix had completely kneecapped implementation of error handlers in the OS (lack of user defined signals and their hierarchy). Error handlers are so much underrated that even books like Code Complete do not mention them.

Each of the three paradigms has pros and cons in terms of code simplicity and runtime cost (in normal/error path), I don't think there is a clear winner.

Java has them now but it didn't at the time (and even now they're kind of bodged in IIRC).

I don't think Java has support for CL condition system-style restarts. You're maybe talking about exceptions that simply don't populate the stack trace?

To clarify a bit, in CL, when throwing an exception, you can optionally register one or more "restarts", which are essentially lambdas of 0 or more parameters. When the exception is thrown, the stack is walked to find the appropriate handler, but it is not unwound. Whoever catches the exception will also receive these restart lambdas. If they chose to call one of the lambdas (passing it the proper parameters), stack unwinding will not happen at all, and execution will continue from the place the exception was thrown. Only if none of the restarts are invoked is the stack unwound, and execution continued from the catch block.

For a somewhat trivial example, the CL runtime throws an exception whenever a variable that was not defined is being read. That exception includes a restart that allows you to define a value for the variable - if this is called, execution will continue where the variable was being read, using this value for the undefined variable. Of course, this would be crazy to do automatically, but it is very nifty when debugging, as this option is presented to you in the REPL.

Pretty sure GP was talking about first-class functions not condition-system &c.