5 ms·

> I don't expect the caller to use the return value if err !=nil and haven't heard anything to the contrary on my team. Yet you admit to following the advice f

> I don't expect the caller to use the return value if err !=nil and haven't heard anything to the contrary on my team. Yet you admit to following the advice for error, returning the zero value for err and making it useful when you do. If you don't have a meaningful error state, why not just return junk? Clearly you recognize the value of making the return values useful, always. Why make exceptions?

eweise 3y ago
if I need to return some person,error how do I return junk for the person? I just return person{}, error. I guess I could fill person out with a bunch of silly values but why would I do that work? If there was some easier way to make a person and it was filled with junk, I wouldn't hesitate to use it because the caller would never use the value.
- 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 ago
    Because 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 ago
      What 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 ago
    On 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 ago
    That'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 ago
        yeah I get it. you're talking common sense but I'm coding in Go.
        randomdata 3y ago
        Yes, 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 ago
        another 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".
ongy 3y ago
No. And GP explictly said they don't tend to make it useful, but only do it when it's easy. Making the return value of e.g. a database handle always "useful" is a ridiculously dangerous idea that can lead to application bugs further down the route becaause some list/get returned an empty value to continue the pattern of "useful" empty values. The main reason there is ever a useful error next to a non-nill err is because go doesn't have a useful way to not do it.

eweise 3y ago

if I need to return some person,error how do I return junk for the person? I just return person{}, error. I guess I could fill person out with a bunch of silly values but why would I do that work? If there was some easier way to make a person and it was filled with junk, I wouldn't hesitate to use it because the caller would never use the value.

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 ago
  Because 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 ago
    What 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 ago
  On 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 ago
  That'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 ago
      yeah I get it. you're talking common sense but I'm coding in Go.
      - randomdata 3y ago
        Yes, 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 ago
      another 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".

ongy 3y ago

No. And GP explictly said they don't tend to make it useful, but only do it when it's easy. Making the return value of e.g. a database handle always "useful" is a ridiculously dangerous idea that can lead to application bugs further down the route becaause some list/get returned an empty value to continue the pattern of "useful" empty values. The main reason there is ever a useful error next to a non-nill err is because go doesn't have a useful way to not do it.