Comment by randomdata

Comment by randomdata 8 days ago

While you might be forced to if faced with a developer who doesn't know what the hell they are doing, that is not the convention.

Consider the case of (T, error). T should always be useable, regardless of error. At very least, if there is nothing more relevant to provide, the function should return the zero value for T. And we know that in Go the zero value is to be made useful. Go Proverb #5.

In practice, this often means something like (*Type, error), where the zero value for *Type (nil) is returned on failure. In which case the caller can check `if t == nil`. No need to consider the error at all. It is there if your requirements dictate a need for the error (e.g. reporting the failure), but for using the result it is entirely unnecessary.

If you leave the caller in a state where T can be invalid, you screwed up horribly or are purposefully being an asshole. Don't do that. That is Go 101 type stuff.

kiitos 7 days ago

> Consider the case of (T, error). T should always be useable, regardless of error.

Go convention dictates that T is only valid (usable) when error is nil. Equivalently, if error is non-nil, then T is invalid (unusable). In either case, the caller is obliged to verify error is non-nil before trying to access T.

Reply View 2 replies

randomdata 7 days ago

You're still only halfway there, as we discussed earlier.
Go calling convention is that you have to assume T is invalid, unless proven otherwise, because we know there are developers who have no business being developers that will screw you over if not careful. The Go style guide promotes documenting in a function comment that your function does return a valid T so that users don't have to guess about whether or not you are competent.
But the convention on the function authoring side is to always ensure T is valid. Just because others shouldn't be writing code does not mean you need to be among them.
As Go promotes limiting use of third-party packages by convention, as a rule most of the functions you call are going to be your own. So most of the time you can be sure that T is valid, regardless of error state. Yes, sometimes you are forced to rely on the error, as we discussed already in earlier comments. Such is life.

Reply View | 1 reply
- kiitos 7 days ago
  
  > the convention on the function authoring side is to always ensure T is valid.
  I'm not sure where you got this idea from. It's not (in the general case) true. But do as you like, of course.
  
  Reply View | 0 replies