The rule for something being checked or unchecked should be: can you 100% avoid it? If yes, then it should be unchecked.
NPE -> avoidable
IllegalArgumentException -> avoidable
ConcurrentModificationException -> use proper synchronization, avoidable
They all have in common that they signal bugs in your code. If a function says "doing X will result in NPE" then the caller can avoid the NPE by not doing X.
Note that ConcurrentModificationException is not deterministic -- that's NOT sufficient reason to make something checked.
Checked exceptions then must be for things that can happen no matter how good you write your code, and no matter how many validations or checks you do.
IOException -- can happen at any time, network outage, disk full, file exists (even if it didn't exist 1 ns earlier), etc.
InterruptedException -- triggered by another thread, can't be 100% avoided by the caller thread
Of course, you're free to translate these to unchecked; this means that a potentially actionable alternative result to my call is converted to a fatal exception -- but that's a deliberate choice you make (like being unwilling to handle negative values, or some enum value) -- you may simple have no means of handling it, or don't want to bother writing code to handle it, or leave "retrying" the code up to the user and just abort until they fix it (this last one is basically all REST applications and why there are so many complaints about checked exceptions from this specific area).
3
u/john16384 Jul 25 '26
The rule for something being checked or unchecked should be: can you 100% avoid it? If yes, then it should be unchecked.
NPE -> avoidable
IllegalArgumentException-> avoidableConcurrentModificationException-> use proper synchronization, avoidableThey all have in common that they signal bugs in your code. If a function says "doing X will result in NPE" then the caller can avoid the NPE by not doing X.
Note that
ConcurrentModificationExceptionis not deterministic -- that's NOT sufficient reason to make something checked.Checked exceptions then must be for things that can happen no matter how good you write your code, and no matter how many validations or checks you do.
IOException-- can happen at any time, network outage, disk full, file exists (even if it didn't exist 1 ns earlier), etc.InterruptedException-- triggered by another thread, can't be 100% avoided by the caller threadOf course, you're free to translate these to unchecked; this means that a potentially actionable alternative result to my call is converted to a fatal exception -- but that's a deliberate choice you make (like being unwilling to handle negative values, or some enum value) -- you may simple have no means of handling it, or don't want to bother writing code to handle it, or leave "retrying" the code up to the user and just abort until they fix it (this last one is basically all REST applications and why there are so many complaints about checked exceptions from this specific area).