4 ms·
>> the entire error thing is absurd. Anders Hejlsberg got th is right many years ago: 9 out of 10 errors are "handled" by a central error handler > This is alm
by dullgiulio 9y ago
>> the entire error thing is absurd. Anders Hejlsberg got th is right many years ago: 9 out of 10 errors are "handled" by a central error handler
> This is almost always unacceptable in production, especially when it comes to mission critical hard/software. You need to be able to handle errors in production that you may not even be able to catch in testing and that means you need to catch all the errors and think critically about what should be done when that error is encountered.
Absolutely. My approach is usually that errors are always wrapped not just returned. The wrapping itself ends up looking almost like code documentation: "could not do X: <previous error>", "error while doing X: <previous error>". Every error string is then unique in the program, easy to grep.
"Could not perform the operation", maybe together with a 500 lines stacktrace in your logs (which are maybe line-by-line bacause that's the default)... you are up to a nice middle of the night debugging session :)
- dvirsky 9y agoExactly, once you wrap errors with their context, or just at the lowest level wrap it with a stack trace, they become much more useful.
- jorgec 9y agoWhen you wrap the error then you are kicking it out. Sooner or later you must catch the error. So, in most case, its just delaying the inevitable.
- rufugee 9y agoThe problem I've found it that you might wrap errors this way, but the libraries you use don't, or approach it differently. So you're either chasing down strings that may or may not be grep'able or you're fighting with delve to track down what's happening. The whole error situation with Go is one of the main drawbacks of the language imho.