3 ms·
The bigger issue is that returning the error without wrapping provides zero context and after a crash you're stuck trying to figure out which of a hundred calls
by marwatk 4y ago
The bigger issue is that returning the error without wrapping provides zero context and after a crash you're stuck trying to figure out which of a hundred calls to Write was responsible for "write error" or some other equally ambiguous message that's nearly impossible to track down.
So you have to resort to a poor man's stack trace:
if err != nil {
return fmt.Errorf("my thing: %w", err)
}
(We use wrapcheck via golangci-lint to enforce it because not having context for an error has bitten us so many times)
- Gibbon1 4y agoThings I tend to do in my firmware for errors. Record the error line number where the error happened. Use __builtin_return_address(0) to fink on the caller. Idle thoughts. Despite it's provenience BASIC's on error goto has merit. The problem with try/catch is creating scoped blocks of code that's annoying. try { // scoped stuff } catch { } vs on_error_goto label; // stuff label: Also a thought is having a separate error_return keyword. And the ability to mark functions with 'no error'
- metaltyphoon 4y agoThe thing with try/catch is that many times, code that throws doesn't have to be handled on the call site! So you can easily have a happy path and kick the bucket to a location where the error can ACTUALLY be handled property.