4 ms·
Logically, in that case you would return nil, just like you do for error. There is no person to return. nil is how Go signifies the absence of something. nil is
by randomdata 3y ago
Logically, in that case you would return nil, just like you do for error. There is no person to return. nil is how Go signifies the absence of something. nil is useful, as proven by error. Why make exceptions?
It’s funny how people forget how to write software as soon as the word error shows up. I don’t get it.
- ongy 3y agoBecause nil panics on member accessors... It's the opposite of what you claim to be the standard in go. Thanks for demonstrating that you forget how to write software around erros.
- randomdata 3y agoWhat are you returning for error in its “junk” state, then? Clearly not nil, else by your assertion your code will panic. error has member accessors you will call - Error() if nothing else. Methinks you’ve not thought this through. What’s it about the word error that trips up programmers like this?
- ongy 3y agoOn top of the issue with nil not being a useful value for most types Nil requires pointer values. I.e. it's impossible to know whether something is a pointer to allow for nil, or because a copy would be prohibitively expensive and therefore references are used, or even because it's into a mutable structure. Go's overlapping of implicit nullability and by value/by reference marker make it entirely useless to build information into APIs / necessarily promotes the value into a different type to use.
- eweise 3y agoThat's not what my team of gofers decided. Apparently zero is better than nil. I know how to write code but Go is its own thing. I mean the idea of returning multiple values is totally goofy in itself.
- 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.