Checked exception
From APIDesign
| Line 1: | Line 1: | ||
[[wikipedia::Checked_exception|Checked exceptions]] are [[Java]] invention and many like to argue that they are the worst invention ever. I like [[APIDesignPatterns:Exceptions|exception]]s and I like [[Checked exception]]s. One day I'll explain why. | [[wikipedia::Checked_exception|Checked exceptions]] are [[Java]] invention and many like to argue that they are the worst invention ever. I like [[APIDesignPatterns:Exceptions|exception]]s and I like [[Checked exception]]s. One day I'll explain why. | ||
| - | There is a really nice thing on [[checked exception]]s: if a method declares that it throws a [[checked exception]], the caller of the method has to handle it. This is really nice language feature, if used at the appropriate place. What is such appropriate place? If one reads a file... | + | There is a really nice thing on [[checked exception]]s: if a method declares that it throws a [[checked exception]], the caller of the method has to handle it. This is a really nice language feature, if used at the appropriate place. What is such appropriate place? If one reads a file one shall be ready for an input/output error - e.g. forcing people to catch {{JDK|java/io|IOException}} seems like the right thing to do. |
| + | |||
| + | Thus in certain situations having [[checked exception]]s is beneficial. On the other hand, throwing [[checked exception]]s in cases where the recovery is unlikely - a frequently mentioned example is {{JDK|javax/xml/parsers|ParserConfigurationException}} - is just going to pollute the client code with useless '''catch''' statements. | ||
| + | |||
[[TBD]] | [[TBD]] | ||
Revision as of 15:30, 1 April 2016
Checked exceptions are Java invention and many like to argue that they are the worst invention ever. I like exceptions and I like Checked exceptions. One day I'll explain why.
There is a really nice thing on checked exceptions: if a method declares that it throws a checked exception, the caller of the method has to handle it. This is a really nice language feature, if used at the appropriate place. What is such appropriate place? If one reads a file one shall be ready for an input/output error - e.g. forcing people to catch IOException seems like the right thing to do.
Thus in certain situations having checked exceptions is beneficial. On the other hand, throwing checked exceptions in cases where the recovery is unlikely - a frequently mentioned example is ParserConfigurationException - is just going to pollute the client code with useless catch statements.
Follow
