[Hermel]

> I disagree -- this is the correct thing to do if you believe it is not possible for the checked exception to occur.

If it is not possible to occur, then it should not be part of the API.

The only time I rethrow a checked exception as an unchecked exception is when the code is still under construction. The default of the eclipse code generator is to log and ignore caught transaction. I think wrapping into an unchecked one is the better default behavior for incomplete code under a "fail fast" policy.

[colejohnson66]

> If it is not possible to occur, then it should not be part of the API.

Ah, but what if it can occur, just never with what you pass in? Suppose a function is documented to throw some checked exception if some parameter is a negative number, but you pass in a positive literal/constant? In such a situation, the checked exception will never occur! With Rust, for example, this is easily done with an `unwrap()` (and, possibly, a comment) to assert said belief, but with checked exceptions, there's no way to force the compiler to squash the required check.

[colanderman]

Example: validation of serialized data followed by deserialization. Deserialization properly should throw a checked exception, since invalid serialized data is very much a thing. But in this case the serialized data is known to be correct (because it passed validation). The checked exception will never occur, and were it to, there's nothing we could do about it, because it reflects a logic error, same as out of bounds array access.

The algebraic data type equivalent of this shows up all the time in functional code -- unwrapping a result type you know can't be Error/None/etc. because of logic. You don't rewrap it and force the caller to deal with a case which logically cannot occur; instead you throw an unchecked exception.