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
This will catch an error if it is the last call is an error, but will let it past otherwise. It is also hard to track down as you don't know what you're looking for, or where you're looking for it, as the function will likely continue running but produce no output, or segfault due to derefrencing a nil pointer (that was supposed to be set by a function that returned an error).
this is worsened by #337.
The text was updated successfully, but these errors were encountered:
Thanks, I will note that none of these address the exact pattern I'm talking about.
namely, #20148 is about forgetting to assign to err, while this issue is about assigning to err, but then forgetting to check it.
Although, they are similar enough to perhaps be parts of the same go vet rule if implemented.
ALTree
changed the title
proposal: cmd/vet: add check for unchecked error return values.
proposal: cmd/vet: add check for unchecked error return values
Jul 20, 2020
If I'm reading this right, I think this is actually a dup of #23142.
They both come from the same underlying cause, but the person who originally opened that issue didn't open it with that title, and it reads more like someone asking for help than proposing a change.
This proposal also is more focused on error values (i.e. variables of type error).
I also would be willing to try to create a prototype for this.
if you are using a lot of functions that return an error value, one mistake you might make is this:
It may look simple in the example, but if you have a bunch of loops and if statements, it could be much harder to see, e.g.
This will catch an error if it is the last call is an error, but will let it past otherwise. It is also hard to track down as you don't know what you're looking for, or where you're looking for it, as the function will likely continue running but produce no output, or segfault due to derefrencing a nil pointer (that was supposed to be set by a function that returned an error).
this is worsened by #337.
The text was updated successfully, but these errors were encountered: