Checked exception
From APIDesign
| Line 6: | Line 6: | ||
| - | There is however one more example: Imagine an exception that needs to be caught when thrown from certain methods, but when it is thrown from other methods, it should behave as as {{JDK|java/lang|RuntimeException}} - e.g. propagate silently. We have seen an example of this recently in our [[Truffle]] project. | + | There is however one more example: Imagine an exception that needs to be caught when thrown from certain methods, but when it is thrown from other methods, it should behave as as {{JDK|java/lang|RuntimeException}} - e.g. propagate silently. We have seen an example of this recently in our [[Truffle]] project. The {{Truffle|com/oracle/truffle/api/interop|InteropException}} should smoothly propagate through many calls, but if invoked via the {{Truffle|com/oracle/truffle/api/interop|ForeignAccess}}'s '''send''' method, we want every caller to handle it. What are our [[API]] design options? |
| + | |||
| + | |||
[[TBD]] | [[TBD]] | ||
Revision as of 16:01, 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.
There is however one more example: Imagine an exception that needs to be caught when thrown from certain methods, but when it is thrown from other methods, it should behave as as RuntimeException - e.g. propagate silently. We have seen an example of this recently in our Truffle project. The InteropException should smoothly propagate through many calls, but if invoked via the ForeignAccess's send method, we want every caller to handle it. What are our API design options?
Follow
