CC @thanm

What's the definition of error handling lines? 'if err != nil {...}' can't be it as errors can be handled in many other ways. Starting with different variable names (or no variable at all) to using switch statements or other control flow mechanisms, sometimes putting them into data structures to inspect them later, as errors are just values.

Also, error cases are usually just as important to test as any other cases. This would give the impression that error handling is somehow less important code.

@pjweinb I feel your pain regarding collecting coverage numbers for code that is very heavily riddled with error handling code.

When writing tests for the new coverage code I had some of the same problems in that the code that writes out new-style coverage data files basically looked like

   func writeTheWholeThing(w io.Writer) error {
      if _, err := w.Write(...); err != nil {
        return err
      }
      <... repeat 50 times...>
      if _, err := w.Write(...); err != nil {
        return err
      }
      return nil
   }

and of course in most normal test runs none of the writes above will fail, and the % statements covered will reflect that of course.

If there is a way you can write your code in a way that allows you to inject errors, that would be my suggestion.

An example (which works well for code like the func above): https://go.googlesource.com/go/+/45b641ce15159e29fa4494b837493042d1e10384/src/runtime/coverage/testdata/harness.go#166

This is a special case of #53271.