Comment by foldr

Comment by foldr 9 days ago

There’s no simple solution when it comes to ignoring errors. Some errors should be ignored and some shouldn’t. So your only lines of defense are linting heuristics and tests.

I would agree that languages which handle errors via exceptions have an advantage here, as they make not ignoring errors the default behavior. But even then, it’s obviously still possible to indicate error conditions of various kinds via return values, in which case they can still be ignored thoughtlessly. (And you also have all the bugs caused by unhandled exceptions to deal with.)

randomdata 8 days ago

> Some errors should be ignored and some shouldn’t.

Assuming the function author followed Go conventions, you never need to consider the error for the sake of using the function. Granted, there are some bad developers out there who will do something strange that will come to bite you, but that is not limited to errors (or any particular language).

You may still need the error for your own application requirements, but application requirements are pretty hard to forget. At very least, you are going to notice that your application is missing a whole entire feature as soon as you start using it.

Reply View 5 replies

kiitos 8 days ago

Any function that returns an error obliges its callers to check that returned error before attempting to use any other returned value.
This is Go 101 type stuff.

Reply View | 4 replies
- 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.
  
  Reply View | 3 replies
  
  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