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.
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
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.