3 ms·
Not at all. Go has an error type, and Go functions have the ability to return zero, one, two, or more items, ordered however the developer likes. An error may b
by margalabargala 2y ago
Not at all. Go has an error type, and Go functions have the ability to return zero, one, two, or more items, ordered however the developer likes. An error may be among those, as desired, and populated as desired.
Some software also writes to both STDOUT and STDERR.
- gf000 2y agoI 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]