At which point it's super easy to identify in code review and slap the developer on the wrist.

I find these arguments that posit incompetent / ignorant developers as a hurdle a bit strange. If they are going to incompetently handle errors wrong when explicitly forced to handle them I can't even imagine how poor their code will be without any assistance from the compiler, and it seems awful to think that you will have no way to identify such poor handling on review - you're going to have to look up every function they call and check if it can return an error or not manually.

i.e. Go. Go can make sure you are aware that an error exists (often. linters do pretty good here too), but it does next to nothing to help you handle it correctly.

From personal experience: yes, little to no compiler help on errors takes an enormous amount of effort by both authors and reviewers (and future readers) to ensure correct handling. The vast majority of the time it's just `if err != nil { return err }`, which is very frequently sub-optimal. But without knowing the call in complete detail, you can't judge if that's true or not... and it may have changed since you last saw it.

IDEs help that kind of "is this optimal/correct" question quite a lot, but they can't verify it either. It's question-marks all the way down, unless you fully know all the code you call, which is often infeasible.

The dev may need to. If you are implementing an interface method and the signature does not include the exception, it must be wrapped in the implementation. You’d like this not to be the case, but it’s better than trying to rewrite major dependencies. I hope they can find a more specific RuntimeException subclass to throw, but that’s a relatively minor quibble.

I’d like to suggest a different POV for your comment on code review. Every method can throw exceptions, that’s life with the JVM. You don’t declare IllegalArgumentException, ArrayOutOfBoundsException, NoSuchElementException, etc. Yet your code needs to deal with it and usually does nothing because it means the element doesn’t make it into a collection, the rest of the object doesn’t get constructed, etc. Avoiding raw RTE, and instead using an RTE subclass that conveys the information you care about works fine. Code review avoids raw RTE, and all places that might care about IO exception causes etc. can process the caused-by of the wrappers.

In what kind of code has this technique been an actual problem? I agree standards and techniques need to be rigorously applied.

You aren't forced to handle it well, you are forced to handle it.

You aren't forced to write your happy path code well, either. What's your point?

The point seemed to be that checked exceptions are a bit of a help, whereas you seem to be responding to an implied claim that they aren't helpful. I think that's why you're being downvoted.

Perhaps. I definitely read it as them saying checked exceptions aren't helpful because you can still handle the errors poorly. But I can see how I might have misinterpreted the intent.

I suppose I wasn't clear. You did misinterpret what I said, I intended to convey the exact opposite.

Once upon a time, I worked on a C++ project with another, experienced developer who kept commenting out -Wall from the Makefiles with the comment, "Nobody has time for that."

You are still forced to deal with it.

In your example, the developer just chose to write crappy code, and there's no defense against that.