[[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 [[exception]]s and I like [[Checked exception]]s. One day I'll explain why.

== Don't Forget to Catch Me ==

== Don't Forget to Catch Me ==

[[TBD]]

[[Category:APIDesignPatterns]]

[[Category:APIDesignPatterns:Exceptions]]

== Summary ==

== Summary ==

We have demonstrated that [[checked exception]]s are beneficial. Not only when dealing with input and output - e.g. {{JDK|java/io|IOException}}, but also in many other cases. We have shown that the biggest problem of [[checked exception]]s - e.g. that one needs to '''decide upfront''' whether an exception is or isn't checked at declaration time isn't problem at all. The [[JVM]] doesn't make difference between normal and [[checked exception]]s and thus one can easily, and without significant drawbacks use [[checked exception]]s as unchecked ones with a simple '''raise''' method. We demonstrated that similar problems are now well recognized the the [[JDK]] itself and proposed few simple [[JDK]] [[API]] extensions that would provide standard solution for the '''checked vs. unchecked''' problem for once and ever.

We have demonstrated that [[checked exception]]s are beneficial. Not only when dealing with input and output - e.g. {{JDK|java/io|IOException}}, but also in many other cases. We have shown that the biggest problem of [[checked exception]]s - e.g. that one needs to '''decide upfront''' whether an exception is or isn't checked at declaration time isn't problem at all. The [[JVM]] doesn't make difference between normal and [[checked exception]]s and thus one can easily, and without significant drawbacks use [[checked exception]]s as unchecked ones with a simple '''raise''' method. We demonstrated that similar problems are now well recognized by the [[JDK]] itself and proposed few simple [[JDK]] [[API]] extensions that would provide standard solution for the '''checked vs. unchecked''' problem for once and ever.

[[TBD]]

[[TBD]]

=== Broken Catch ===

=== Broken Catch ===

One more problem we have noticed so far is related to wrong assumption in a generic catch. Following code may throw {{JDK|java/lang|ClassCastException}}:

One more problem we have noticed so far is related to wrong assumption in a wide catch - a catch that tries to catch everything. Following code may throw {{JDK|java/lang|ClassCastException}}:

<source lang="java">

<source lang="java">

<source lang="java">

<source lang="java">

throw new InteropRuntimeException(new UnknownIdentifier("name"));

throw new InteropRuntimeException(new UnknownIdentifier("name"));

// which could be simplified and hidden into a factory method:

</source>

and this could be further simplified and hidden into static factory method:

throw UnknownIdentifierException.raise("name");

throw UnknownIdentifierException.raise("name");

</source>

</source>

== Don't Forget to Catch Me ==

== Don't Forget to Catch Me ==

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.

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 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.

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.

 

== Can't Decide Upfront ==

== Can't Decide Upfront ==

=== Unchecking Checked Exception ===

=== Unchecking Checked Exception ===

Luckily, if one knows the difference between [[source compatibility]] and [[binary compatibility]] one can realize that the [[JVM]] doesn't know anything about the difference between {{JDK|java/lang|RuntimeException}} and checked {{JDK|java/lang|Exception}} - it is all just a [[Java]] language construct. Other languages built on top of [[JVM]] may ignore it. And that is what we decided to do.

Luckily, if one knows the difference between [[SourceCompatibility|source compatibility]] and [[binary compatibility]] one can realize that the [[JVM]] doesn't know anything about the difference between {{JDK|java/lang|RuntimeException}} and checked {{JDK|java/lang|Exception}} - it is all just a [[Java]] language construct. Other languages built on top of [[JVM]] may ignore it. And that is what we decided to do.

We designed a [[checked exception]] {{Truffle|com/oracle/truffle/api/interop|InteropException}} (and its subclasses) and added a '''raise''' method to throw the exception as unchecked one. The usage is simple:

We designed a [[checked exception]] {{Truffle|com/oracle/truffle/api/interop|InteropException}} (and its subclasses) and added a '''raise''' method to throw the exception as unchecked one. The usage is simple:

</source>

</source>

However this still suffers from the duality of exceptions. In situations where one needs to be sure, one needs to catch both exceptions '''InteropRuntimeException''' as well as {{Truffle|com/oracle/truffle/api/interop|InteropException}}, which is again a reason for few to claim that [[checked exception]]s are bad.

However this still suffers from the duality of exceptions. In situations where one needs to be sure, one needs to catch both exceptions '''InteropRuntimeException''' as well as {{Truffle|com/oracle/truffle/api/interop|InteropException}}, which is again a reason for a few to claim that [[checked exception]]s are bad.

=== Unchecking Checked Exception ===

=== Unchecking Checked Exception ===

</source>

</source>

However this still suffers from the duality of exceptions. In situations where needs to be sure, one needs to catch both exceptions '''InteropRuntimeException''' as well as {{Truffle|com/oracle/truffle/api/interop|InteropException}}, which is again a reason for few to claim that [[checked exception]]s are bad.

However this still suffers from the duality of exceptions. In situations where one needs to be sure, one needs to catch both exceptions '''InteropRuntimeException''' as well as {{Truffle|com/oracle/truffle/api/interop|InteropException}}, which is again a reason for few to claim that [[checked exception]]s are bad.

=== Unchecking Checked Exception ===

=== Unchecking Checked Exception ===

== Can't Decide Upfront ==

== Can't Decide Upfront ==

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?

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 a {{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?

=== Duplicate the Exceptions ===

=== Duplicate the Exceptions ===