3 ms·
I know, special cased may have been better worded as "just a convention". My point is, this is not much different than using a thread-local variable, like errno
by gf000 2y ago
I know, special cased may have been better worded as "just a convention". My point is, this is not much different than using a thread-local variable, like errno, and adds useless confusion - your return values represent n*m values, while there is only n+m case with proper error semantics.
Re STDERR: but shells don't decide whether a program execution failed on having written to STDERR, but by the returned singular error code.
- margalabargala 2y agoI agree with everything you've written in this comment. I'd like to split a hair here and say, this is a "Go's standard library" problem, and not a "Go language" problem. Good API design for a software package should have proper error semantics. Good API design for a language, allows for flexibility in actual implementation, alongside standards that say "you SHOULD do this".
- gf000 2y agoDisagree. This level of convention is inseparable from the language. Not doing the conventional error return in go would be akin to using a Return sum type in reverse, putting the success value into the Error case..
- deleted 2y ago[deleted]