You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While writing a similar tool, I ended up spending some time pondering under what circumstances Go allows a value to be generated-but-not-consumed. And there aren't all that many; it's mostly function call return values, since functions could have side-effects.
So could channel receives. So consider:
func foo(x chan error) {
<-x
}
I would argue that this constitutes "failing to check an error".
The text was updated successfully, but these errors were encountered:
I like the idea. I'm a bit fuzzy on some of the details.
Ignoring for a moment that channel receives are a bit different to analyze than function calls, I'm wondering about the extent of channel receive scenarios that would be considered unchecked. Would we consider any channel receive that gets an error, and discards it, an errcheck error?
In addition to your example, what about these?
x := make(chan error)
for range x {
}
x := make(chan error)
select {
case <-x:
case <-y:
}
x := make(chan error)
y := make(chan error)
y <- <-x
3 is kind of funny and I just included it as a pseudo test case. We aren't assigning the error to anything, but we are using it. (Of course, intuitively, this would be "not an errcheck error")
So, in the tool I wrote, I ignore questions like "channel receives" and "function calls", and just look at the type of the expression of an ExprStmt. But it occurs to me that range and select calls are also arguably examples, and I should think about that more.
I would consider any form of "use" (sending to a channel, passing to a function, etc.) to count as a valid "use". On the other hand, it seems to me that I wasn't thinking about the range and select cases. There's nothing corresponding for the function call case I was originally thinking about, so I didn't really get into that space.
So I think I would consider the first two of those to be examples of "this is an error that isn't being checked".
While writing a similar tool, I ended up spending some time pondering under what circumstances Go allows a value to be generated-but-not-consumed. And there aren't all that many; it's mostly function call return values, since functions could have side-effects.
So could channel receives. So consider:
I would argue that this constitutes "failing to check an error".
The text was updated successfully, but these errors were encountered: