8 ms·

> 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. Equ

• randomdata 2y 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.
  • kiitos 2y 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.