How, exactly, are going to forget a necessary `if err != nil` without your test suite blowing up?
If you do hate other developers for some reason, why not leave out some `err != nil`s to really drive home your hatred towards them?
A language with generics and sum types (so you can implement something like Either, Try, or Result) doesn't let you use the result of a fallible function call without handling the error explicitly. And if the result is unit/void, most compilers/linters will still warn you if you haven't used the Either/Try/Result type that's returned.
But ultimately it doesn't matter. Write in whatever language you feel comfortable and most productive.
Well, unless you're starting a new security-sensitive project and want to write in C. Just... stop.
Assuming you don't hate other developers, and given the tests you would write in any language, how do you foresee missing an error branch? Again, not specifically trying to test for something that a sufficiently advanced type system would catch, just your regular level documenting that demonstrates to other developers that you don't hate them.
> then you can just as easily forget to add a proper test for that error condition
If an error condition is easily forgotten in the documentation, then who cares about the implementation thereof? It is obviously not important. In fact, it is arguable that your program is incorrect if you do handle the condition in such a case.
But in this case you don't need to know about what paths have been executed. It will be obvious that an error path was not handled when your program does not adhere to function that is documented.