Timeline for Any downsides to rethrowing the *cause* of a checked exception as an unchecked exception?
Current License: CC BY-SA 4.0
Post Revisions
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 12, 2021 at 21:02 | comment | added | john16384 | Perhaps you may want to choose a different venue for this discussion, I've already made up my mind on this. | |
| Nov 12, 2021 at 17:24 | comment | added | Robert Harvey | Perhaps your logic is backwards. This states: “If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.” | |
| Nov 12, 2021 at 16:53 | comment | added | Robert Harvey | Hmm... Lets check that assumption (no pun intended): FileNotFoundException is a checked exception, even though it could easily be solved by providing the correct file name. | |
| Nov 12, 2021 at 16:18 | comment | added | john16384 |
Perhaps that is worded a bit poorly. It means you should declare an exception as checked only if callers can't prevent the exceptional situation from happening, and neither could the code that throws it. If callers can easily prevent the problem (by passing in correct parameters for example) then it shouldn't be checked. If throwers can easily handle the case, then they shouldn't be throwing anything at all. An IOException is something that is outside the control of both the caller and the throwing code because external systems are involved.
|
|
| Nov 12, 2021 at 15:25 | comment | added | Robert Harvey | What does "Exceptions should only be checked when they're out of control of both the caller and receiver" mean? | |
| Nov 12, 2021 at 14:28 | history | edited | john16384 | CC BY-SA 4.0 |
deleted 2 characters in body
|
| Nov 12, 2021 at 14:20 | history | asked | john16384 | CC BY-SA 4.0 |