3 ms·
Go error handling is nice, but not super mandatory. I’ve seen functions only returning an error being called without the error being assigned to anything and n
by jiehong 2y ago
Go error handling is nice, but not super mandatory.
I’ve seen functions only returning an error being called without the error being assigned to anything and never checked. The compiler does not care, only go ci lint would block that.
I’ve also seen a function returning a value and and error, and the error being mapped to _ on the caller side. Compiler and linter are fine with that (and sometimes it’s mandatory with some weird libraries).
Lastly, a nitpick: should functions return (value, error, or (error, value)? The former is a convention, but the latter happens sometimes in some libraries.
- daveliepmann 2y ago>should functions return (value, error), or (error, value)? a benefit of using maps with error keys :D semantic rather than positional destructuring. also avoids that needlessly obfuscatory Left and Right terminology for Either monads
- ncruces 2y ago> I’ve also seen a function returning a value and and error, and the error being mapped to _ on the caller side. Compiler and linter are fine with that (and sometimes it’s mandatory with some weird libraries). Yes, that's the way to explicitly ignore the error. Ignoring the result, instead of attributing to the blank identifier _ , is bad form (unless you're doing something like defer a Close).