Timeline for How to deal with IOException when file to be opened already checked for existence?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 16, 2017 at 11:00 | vote | accept | Johnathan | ||
| Jan 15, 2017 at 20:52 | comment | added | Johnathan | @Periata Breatta, I think this is the kind of answer I was looking for. I constructed the above code as an example to highlight my general case but obviously it wasn't the best example. The method here seems good to me. I wanted to make my code not needing to have loads of exceptions in function signature to preserve the functions closedness. | |
| Jan 15, 2017 at 19:23 | comment | added | user22815 |
You said it yourself: "guidelines" not "rules." I see no problem with a catch-and-rethrow of AssertionError. The reason why some people say not to catch errors is because there is typically not much that can be done to fix whatever caused them, or there is nothing that can be done after they are thrown (e.g. out of memory).
|
|
| Jan 15, 2017 at 19:19 | comment | added | Periata Breatta |
@Snowman - Yes, I would recommend this except that many Java design guidelines state that subclasses of Error should never be caught, whereas catching and logging is the appropriate behaviour here.
|
|
| Jan 15, 2017 at 19:16 | comment | added | user22815 | AssertionError already exists and more clearly captures the intent: some invariant was violated. | |
| Jan 15, 2017 at 19:08 | history | answered | Periata Breatta | CC BY-SA 3.0 |