4 ms·
> Apparently zero is better than nil. Zero often is better than nil. Consider something like atoi. If it fails, 0 is often exactly what you want. No need to ca
by randomdata 3y ago
> Apparently zero is better than nil.
Zero often is better than nil. Consider something like atoi. If it fails, 0 is often exactly what you want. No need to care about any error state. Although the error state is there if your situation is different. The caller gets to choose.
But for something like a person that doesn't exist, nil is almost assuredly the appropriate representation. You didn't end up with an empty person, or a made up person, you ended up with no person. nil is how the absence of something is represented. Same reason you return nil when there is no error.
There seems to be no disagreement that nil is the proper return value for cases where there is no error. Why would no person be different?
> I mean the idea of returning multiple values is totally goofy in itself.
It is, but then again so is accepting multiple inputs. Neither is mathematically sound, but they have proven useful in practice.
- eweise 3y agoyeah I get it. you're talking common sense but I'm coding in Go.
- randomdata 3y agoYes, the biggest mistake Go made was introducing the error keyword. It should have used banana. If it were (T, banana), nobody would have trouble with these concepts. There's just something about the word error that causes programmers to lose their mind for some reason.
- bouncycastle 3y agoanother example is when reading from a file using io.Reader. EOF is returned as an error, but you still need to check the slice for any new bytes that we read before the EOF. A lot of errors are actually good to have, and still return critical data despite being an "error".
- tsimionescu 3y ago> Consider something like atoi. If it fails, 0 is often exactly what you want. No need to care about any error state. No, 0 is a bogus value if atoi() failed. 5 would be exactly as appropriate. If I'm parsing a form to find a user's age and they entered "old", their age is definitely not 0. I can't even imagine a scenario where I'd care what value atoi() returned if it returned an error.
- randomdata 3y ago> No, 0 is a bogus value No. 0 is the integer's (what i in atoi identifies) zero value, which carries the expectation of being useful. The problem here is that your example is using the wrong type. Age is not an integer, it is an age. Use an age type that defines the proper semantics for age when you what you have is an age. Not even the best type system can stop a bad programmer choosing to use the wrong types. Stop being a bad programmer, I guess. No amount of tooling can fix that problem, I'm afraid.
- tsimionescu 3y ago0 is a perfectly good age, plenty of humans have been 0 years old. The point is simply that the first return value of atoi() if the second is non-nil is meaningless. Atoi would have been exactly as useful if it had been defined that atoi() returns 167 and an error if it can't interpret the string as an integer. Code which proceeds to use the first return value of atoi() if the second one is non-nil is wrong code, even if it happens to work for some convoluted scenarios. Edit to note: atoi() actually doesn't always return 0 if it fails: if the second return is err.Err=ErrRange, then the first is the max value that can fit on 32 bits.