Checked Exceptions
Checked Exceptions (aka a lively debate!)
| Checked Exceptions (aka a lively debate!) |
|---|
| Convenor: Álvaro |
Participants:
|
| Summary:
Questions
Answers 1. It is basically an unexpected flow path 2. - Runtime. (expected to be) never unrecoverable. The name may be misleading (all exceptions are thrown at runtime) - Checked. Might be recoverable. The compiler forces you to handle them (either catching or throwing them) - Errors. Unrecoverable. Thrown by the JVM. Out of program's responsibility. Don't use exceptions for flow control, even in the name of "clean code". Advanced programmers may be annoyed by checked exceptions as they already know them, but they really help beginners (given that they don't ignore them). Java 7 multicatch really helps to reduce the clutter. 3. Yes, so do something (not just log or ignore them). If you need to exit from the program, propagate it to the upper layer. 4. Yes, but do not rename existing exceptions. Create a hierarchy of exceptions with appropriate exceptions at each layer 5. That's really a hack, and should not be used when using JRE code. However, it may be needed for other frameworks which only throw runtime exceptions 6. It would be a nice addition if the java compiler may issue a warning (or better: a "hint") if a method declares in its signature that it throws a runtime exception. While it should be declared in the javadoc, (unfortunately) not every developer reads the javadoc. 7. Yes, to hide implementation details and show a consistent exception to the right layer. 8. Unanswered 9. Apparently, yes 10. Good point! They may be treated as runtime exceptions as recoverability may be extremely difficult 11. Write him an email ;) 12. This mostly happens with external libraries/frameworks. There's nothing that could be done. Just file a bug |
| Recommendations:
(as above) |
