Checked exception - Revision history

JaroslavTulach at 08:49, 16 June 2016

JaroslavTulach — Thu, 16 Jun 2016 08:49:12 GMT

←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 */

JaroslavTulach — Tue, 05 Apr 2016 03:49:58 GMT

Summary

←Older revision		Revision as of 03:49, 5 April 2016
Line 204:		Line 204:


-	[[~~TBD~~]]	+	[[Category:APIDesignPatterns]]
		+	[[Category:APIDesignPatterns:Exceptions]]

JaroslavTulach: /* Summary */

JaroslavTulach — Tue, 05 Apr 2016 03:47:26 GMT

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 */

JaroslavTulach — Tue, 05 Apr 2016 03:46:10 GMT

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 */

JaroslavTulach — Tue, 05 Apr 2016 03:16:35 GMT

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 */

JaroslavTulach — Tue, 05 Apr 2016 03:12:07 GMT

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 */

JaroslavTulach — Mon, 04 Apr 2016 12:17:16 GMT

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 */

JaroslavTulach — Mon, 04 Apr 2016 12:16:04 GMT

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 */

JaroslavTulach — Mon, 04 Apr 2016 12:15:44 GMT

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 */

JaroslavTulach — Mon, 04 Apr 2016 12:13:52 GMT

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