JaroslavTulach at 08:49, 16 June 2016 - 2016-06-16 08:49:12

←Older revision Revision as of 08:49, 16 June 2016
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 [[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 ==

JaroslavTulach: /* Summary */ - 2016-04-05 03:49:58

Summary

←Older revision Revision as of 03:49, 5 April 2016
Line 204: Line 204:
-
[[TBD]]
+
[[Category:APIDesignPatterns]]
 +
[[Category:APIDesignPatterns:Exceptions]]

JaroslavTulach: /* Summary */ - 2016-04-05 03:47:26

Summary

←Older revision Revision as of 03:47, 5 April 2016
Line 201: Line 201:
== 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]]

JaroslavTulach: /* Broken Catch */ - 2016-04-05 03:46:10

Broken Catch

←Older revision Revision as of 03:46, 5 April 2016
Line 173: Line 173:
=== 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">

JaroslavTulach: /* Wrap the Exceptions */ - 2016-04-05 03:16:35

Wrap the Exceptions

←Older revision Revision as of 03:16, 5 April 2016
Line 31: Line 31:
<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:
 +
<source lang="java">
throw UnknownIdentifierException.raise("name");
throw UnknownIdentifierException.raise("name");
</source>
</source>

JaroslavTulach: /* Don't Forget to Catch Me */ - 2016-04-05 03:12:07

Don't Forget to Catch Me

←Older revision Revision as of 03:12, 5 April 2016
Line 3: Line 3:
== 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 ==

JaroslavTulach: /* Unchecking Checked Exception */ - 2016-04-04 12:17:16

Unchecking Checked Exception

←Older revision Revision as of 12:17, 4 April 2016
Line 39: Line 39:
=== 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:

JaroslavTulach: /* Wrap the Exceptions */ - 2016-04-04 12:16:04

Wrap the Exceptions

←Older revision Revision as of 12:16, 4 April 2016
Line 35: Line 35:
</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 ===

JaroslavTulach: /* Wrap the Exceptions */ - 2016-04-04 12:15:44

Wrap the Exceptions

←Older revision Revision as of 12:15, 4 April 2016
Line 35: Line 35:
</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 ===

JaroslavTulach: /* Can't Decide Upfront */ - 2016-04-04 12:13:52

Can't Decide Upfront

←Older revision Revision as of 12:13, 4 April 2016
Line 9: Line 9:
== 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 ===