From joe.darcy at oracle.com Mon May 3 17:25:00 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 03 May 2010 17:25:00 -0700 Subject: Multi-catch/final rethrow Message-ID: <4BDF695C.8000306@oracle.com> Greetings, As alluded to as a possibility previously [1], I'm happy to announce that improved exception handling with multi-catch and final rethrow will be part of an upcoming JDK 7 build. Improved exception handling is joining other Project Coin features implemented in the repository after successful experiences with a multi-catch implementation developed by Maurizio Cimadamore. Maurizio's work also revealed and corrected a flaw in the originally proposed static analysis for the set of exception that can be rethrown [2]: > [a] final catch parameter is treated as throwing precisely those > exception types that > - the try block can throw, > - no previous catch clause handles, and > - is a subtype of one of the types in the declaration of the catch > parameter Consider a final rethrow statement as below where the dynamic class of a thrown exception differs from the static type (due to a cast in this case): class Neg04 { static class A extends Exception {} static class B extends Exception {} void test(boolean b1, boolean b2) throws B { try { if (b1) { throw new A(); } else if (b2) { throw new B(); } else { throw (Throwable)new Exception(); } } catch (A e) {} catch (final Exception e) { throw e; } catch (Throwable t) {} } } The set of exceptions thrown by the try block is computed {A, B, Throwable}; therefore, the set of exceptions that can be rethrown is the set of exceptions from the try block: * minus A, handled by a previous catch clause, giving {B, Throwable} * minus Throwable since Throwable is not a subtype of one of the types declared for the catch parameter (just Exception in this case), leaving just {B} However, if an Exception is thrown from the try it should be caught in the "catch(final Exception e)" clause even if the exception is cast to Throwable since catch clauses work based on the runtime class of the exceptions being thrown. To address this, the third clause is changed to > - is a subtype/supertype of one of the types in the declaration of the > catch parameter More formally, this clause covers computing a join over the set of thrown exceptions, eliminating subtypes. In the example above {Throwable} is computed as the set of exceptions being throwable from the try block. This is then intersected with the exceptions that can be caught by the try block, resulting in {Exception}, a properly sound result. Very general exception types being thrown by a try block would reduce the utility of multi-catch since only imprecise information would be available. Fortunately, from analyzing the JDK sources, throwing a statically imprecise exception seems rare, indicating multi-catch with the amended specification should still be very be helpful in practice. Today the adventurous can apply a changest [3] to a copy of the JDK 7 langtrools repository and build get a javac supporting this feature. Otherwise, the change will appear in promoted JDK 7 builds in due course. [4] -Joe [1] "Project Coin: Post-Devoxx Update, closures and exception handling," http://blogs.sun.com/darcy/entry/projec_coin_post_devoxx_closures [2] "Improved Exception Handling for Java," http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000003.html [3] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a6f2911a7c55 [4] http://download.java.net/jdk7/binaries/ From neal at gafter.com Mon May 3 18:50:07 2010 From: neal at gafter.com (Neal Gafter) Date: Mon, 3 May 2010 18:50:07 -0700 Subject: hg: jdk7/tl/langtools: 6943289: Project Coin: Improved Exception Handling for Java (aka 'multicatch') In-Reply-To: <20100504001446.C42B544D11@hg.openjdk.java.net> References: <20100504001446.C42B544D11@hg.openjdk.java.net> Message-ID: This will serve as a code review "Disjoint" is not a correct name. The word you should be looking for is "Disjunct". The code as written allows types that are not disjoint (such as "Exception | IOException"). It also allows repeated types (such as "Exception | Exception"). This (name issue) will be more important if this concept is extended to support exception transparency in project lambda. In that case the disjuncts are not necessarily disjoint, especially in the presence of (exception) type parameters. The phrase "multi-catch statement" appears in one of the diagnostics, but the multi-catch form is not a statement. I would have appreciated a chance to review this code before it was pushed to the langtools repository. Still, you should be congratulated for getting this submitted under the wire before the final langtools integration (5/21) preceding jdk7 feature-complete. On Mon, May 3, 2010 at 5:14 PM, wrote: > Changeset: a6f2911a7c55 > Author: mcimadamore > Date: 2010-05-03 17:12 -0700 > URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a6f2911a7c55 > > 6943289: Project Coin: Improved Exception Handling for Java (aka > 'multicatch') > Reviewed-by: jjg, darcy > > + src/share/classes/com/sun/source/tree/DisjointTypeTree.java > ! src/share/classes/com/sun/source/tree/Tree.java > ! src/share/classes/com/sun/source/tree/TreeVisitor.java > ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java > ! src/share/classes/com/sun/source/util/TreeScanner.java > ! src/share/classes/com/sun/tools/javac/code/Flags.java > ! src/share/classes/com/sun/tools/javac/code/Source.java > ! src/share/classes/com/sun/tools/javac/comp/Attr.java > ! src/share/classes/com/sun/tools/javac/comp/Flow.java > ! src/share/classes/com/sun/tools/javac/jvm/Gen.java > ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java > ! src/share/classes/com/sun/tools/javac/resources/compiler.properties > ! src/share/classes/com/sun/tools/javac/tree/JCTree.java > ! src/share/classes/com/sun/tools/javac/tree/Pretty.java > ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java > ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java > ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java > ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java > ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java > + test/tools/javac/multicatch/Neg01.java > + test/tools/javac/multicatch/Neg01.out > + test/tools/javac/multicatch/Neg02.java > + test/tools/javac/multicatch/Neg02.out > + test/tools/javac/multicatch/Neg03.java > + test/tools/javac/multicatch/Neg03.out > + test/tools/javac/multicatch/Neg04.java > + test/tools/javac/multicatch/Neg04.out > + test/tools/javac/multicatch/Pos01.java > + test/tools/javac/multicatch/Pos02.java > + test/tools/javac/multicatch/Pos03.java > + test/tools/javac/multicatch/Pos04.java > + test/tools/javac/multicatch/Pos05.java > > From scolebourne at joda.org Tue May 4 00:41:05 2010 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 4 May 2010 08:41:05 +0100 Subject: Multi-catch/final rethrow In-Reply-To: <4BDF695C.8000306@oracle.com> References: <4BDF695C.8000306@oracle.com> Message-ID: While I'm sure many will welcome these additions, I must be clear that I find the syntax approach used for final rethrow to be undesirable. The change that the developer makes (adding 'final') is too subtle and unconnected to the task at hand. It also leads to some odd behaviour (assuming I've understood the spec): public void process() { try { System.out.println("No exception thrown here..."); } catch (final Exception ex) { throw ex; } } Here, we throw an exception without it appearing in the throws clause of the method. I'm of the opinion that will be pretty confusing to newcomers (and even some of us old-hands). Note that I don't have a great alternative. I suspect a 'rethrow' keyword would probably be best (dovetailed with the 'final' part for obvious reasons). Given that we can't use a new keyword, perhaps the 'throws final' might work. Stephen On 4 May 2010 01:25, wrote: > Greetings, > > As alluded to as a possibility previously [1], I'm happy to announce > that improved exception handling with multi-catch and final rethrow will > be part of an upcoming JDK 7 build. ?Improved exception handling is > joining other Project Coin features implemented in the repository after > successful experiences with a multi-catch implementation developed by > Maurizio Cimadamore. > > Maurizio's work also revealed and corrected a flaw in the originally > proposed static analysis for the set of exception that can be rethrown [2]: > >> ?[a] final catch parameter is treated as throwing precisely those >> exception types that >> ? ? - the try block can throw, >> ? ? - no previous catch clause handles, and >> ? ? - is a subtype of one of the types in the declaration of the catch >> parameter > > Consider a final rethrow statement as below where the dynamic class of a > thrown exception differs from the static type (due to a cast in this case): > > class Neg04 { > ?static class A extends Exception {} > ?static class B extends Exception {} > > ?void test(boolean b1, boolean b2) throws B { > ? ? ?try { > ? ? ? ? ?if (b1) { > ? ? ? ? ? ? ?throw new A(); > ? ? ? ? ?} else if (b2) { > ? ? ? ? ? ? ?throw new B(); > ? ? ? ? ?} else { > ? ? ? ? ? ? ?throw (Throwable)new Exception(); > ? ? ? ? ?} > ? ? ?} > ? ? ?catch (A e) {} > ? ? ?catch (final Exception e) { > ? ? ? ? ?throw e; > ? ? ?} > ? ? ?catch (Throwable t) {} > ?} > } > > The set of exceptions thrown by the try block is computed {A, B, > Throwable}; therefore, the set of exceptions that can be rethrown is the > set of exceptions from the try block: > > * minus A, handled by a previous catch clause, giving {B, Throwable} > * minus Throwable since Throwable is not a subtype of one of the types > declared for the catch parameter (just Exception in this case), leaving > just {B} > > However, if an Exception is thrown from the try it should be caught in > the "catch(final Exception e)" clause even if the exception is cast to > Throwable since catch clauses work based on the runtime class of the > exceptions being thrown. > > To address this, the third clause is changed to > >> - is a subtype/supertype of one of the types in the declaration of the >> catch ?parameter > > More formally, this clause covers computing a join over the set of > thrown exceptions, eliminating subtypes. ?In the example above > {Throwable} is computed as the set of exceptions being throwable from > the try block. ?This is then intersected with the exceptions that can be > caught by the try block, resulting in {Exception}, a properly sound result. > > Very general exception types being thrown by a try block would reduce > the utility of multi-catch since only imprecise information would be > available. ?Fortunately, from analyzing the JDK sources, throwing a > statically imprecise exception seems rare, indicating multi-catch with > the amended specification should still be very be helpful in practice. > > Today the adventurous can apply a changest [3] to a copy of the JDK 7 > langtrools repository and build get a javac supporting this feature. > Otherwise, the change will appear in promoted JDK 7 builds in due > course. [4] > > -Joe > > [1] "Project Coin: Post-Devoxx Update, closures and exception handling," > http://blogs.sun.com/darcy/entry/projec_coin_post_devoxx_closures > > [2] "Improved Exception Handling for Java," > http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000003.html > > [3] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a6f2911a7c55 > > [4] http://download.java.net/jdk7/binaries/ > > From Ulf.Zibis at gmx.de Tue May 4 02:30:10 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 04 May 2010 11:30:10 +0200 Subject: Multi-catch/final rethrow In-Reply-To: <4BDF695C.8000306@oracle.com> References: <4BDF695C.8000306@oracle.com> Message-ID: <4BDFE922.3060805@gmx.de> Am 04.05.2010 02:25, schrieb joe.darcy at oracle.com: > Greetings, > > As alluded to as a possibility previously [1], I'm happy to announce > that improved exception handling with multi-catch and final rethrow will > be part of an upcoming JDK 7 build. > Great! > } else { > throw (Throwable)new Exception(); > I'm wondering that a cast to a throw is valid syntax, or _in other words_, what should such a syntax be good for ??? In fact, an Exception instance is thrown, and should be caught by catch (Exception e). Or not ? > To address this, the third clause is changed to > > >> - is a subtype/supertype of one of the types in the declaration of the >> catch parameter >> Does that mean, that following variation wouldn't rethrow Exception("b3") (and (Throwable)new Exception() too?), as it is nor subtype nor supertype of Exception, as it is itself ? That IMO would be weird syntax. class Neg04 { static class A extends Exception {} static class B extends Exception {} void test(boolean b1, boolean b2, boolean b3) throws B { try { if (b1) { throw new A(); } else if (b2) { throw new B(); } else if (b3) { throw new Exception("b3"); } else { throw (Throwable)new Exception(); } } catch (A e) {} catch (final Exception e) { throw e; } catch (Throwable t) {} } } -Ulf From scolebourne at joda.org Tue May 4 08:42:52 2010 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 4 May 2010 16:42:52 +0100 Subject: Multi-catch/final rethrow In-Reply-To: <4BE03CEE.1060704@oracle.com> References: <4BDF695C.8000306@oracle.com> <4BE03CEE.1060704@oracle.com> Message-ID: Agreed - that is the perspective from a compiler writer. Its just "better flow analysis". But most developers don't understand that. The new code says "throw", the type it is throwing is "Exception", yet it isn't declared in the method signature - the exception disappears into thin air! (at least in the eyes of many devs). There be a puzzler here... Stephen On 4 May 2010 16:27, Jonathan Gibbons wrote: > Stephen, > > Regarding your example, there is no new syntax involved.? If you take your > "process" method, change "Exception" to "RuntimeException", and wrap it in a > class, you'll find it compiles just fine with JDK 6, so it should not be too > unfamiliar even to some of you "old hands". > > $ more Test.java > class Test { > > public void process() { > ? try { > ??? System.out.println("No exception thrown here..."); > ? } catch (final RuntimeException ex) { > ??? throw ex; > ? } > } > > } > $ /opt/jdk/1.6.0/bin/javac Test.java > $ > > The only thing that has changed, as regards your example as written, is that > now javac can do better flow analysis of the try block to determine that no > checked exceptions can be thrown, and so none need to be listed in the > throws clause of the method declaration. > > -- Jon > > > > > > Stephen Colebourne wrote: > > While I'm sure many will welcome these additions, I must be clear that > I find the syntax approach used for final rethrow to be undesirable. > The change that the developer makes (adding 'final') is too subtle and > unconnected to the task at hand. > > It also leads to some odd behaviour (assuming I've understood the spec): > > public void process() { > try { > System.out.println("No exception thrown here..."); > } catch (final Exception ex) { > throw ex; > } > } > > Here, we throw an exception without it appearing in the throws clause > of the method. I'm of the opinion that will be pretty confusing to > newcomers (and even some of us old-hands). > > Note that I don't have a great alternative. I suspect a 'rethrow' > keyword would probably be best (dovetailed with the 'final' part for > obvious reasons). Given that we can't use a new keyword, perhaps the > 'throws final' might work. > > Stephen > > > On 4 May 2010 01:25, wrote: > > > Greetings, > > As alluded to as a possibility previously [1], I'm happy to announce > that improved exception handling with multi-catch and final rethrow will > be part of an upcoming JDK 7 build. ?Improved exception handling is > joining other Project Coin features implemented in the repository after > successful experiences with a multi-catch implementation developed by > Maurizio Cimadamore. > > Maurizio's work also revealed and corrected a flaw in the originally > proposed static analysis for the set of exception that can be rethrown [2]: > > > > ?[a] final catch parameter is treated as throwing precisely those > exception types that > ? ? - the try block can throw, > ? ? - no previous catch clause handles, and > ? ? - is a subtype of one of the types in the declaration of the catch > parameter > > > Consider a final rethrow statement as below where the dynamic class of a > thrown exception differs from the static type (due to a cast in this case): > > class Neg04 { > ?static class A extends Exception {} > ?static class B extends Exception {} > > ?void test(boolean b1, boolean b2) throws B { > ? ? ?try { > ? ? ? ? ?if (b1) { > ? ? ? ? ? ? ?throw new A(); > ? ? ? ? ?} else if (b2) { > ? ? ? ? ? ? ?throw new B(); > ? ? ? ? ?} else { > ? ? ? ? ? ? ?throw (Throwable)new Exception(); > ? ? ? ? ?} > ? ? ?} > ? ? ?catch (A e) {} > ? ? ?catch (final Exception e) { > ? ? ? ? ?throw e; > ? ? ?} > ? ? ?catch (Throwable t) {} > ?} > } > > The set of exceptions thrown by the try block is computed {A, B, > Throwable}; therefore, the set of exceptions that can be rethrown is the > set of exceptions from the try block: > > * minus A, handled by a previous catch clause, giving {B, Throwable} > * minus Throwable since Throwable is not a subtype of one of the types > declared for the catch parameter (just Exception in this case), leaving > just {B} > > However, if an Exception is thrown from the try it should be caught in > the "catch(final Exception e)" clause even if the exception is cast to > Throwable since catch clauses work based on the runtime class of the > exceptions being thrown. > > To address this, the third clause is changed to > > > > - is a subtype/supertype of one of the types in the declaration of the > catch ?parameter > > > More formally, this clause covers computing a join over the set of > thrown exceptions, eliminating subtypes. ?In the example above > {Throwable} is computed as the set of exceptions being throwable from > the try block. ?This is then intersected with the exceptions that can be > caught by the try block, resulting in {Exception}, a properly sound result. > > Very general exception types being thrown by a try block would reduce > the utility of multi-catch since only imprecise information would be > available. ?Fortunately, from analyzing the JDK sources, throwing a > statically imprecise exception seems rare, indicating multi-catch with > the amended specification should still be very be helpful in practice. > > Today the adventurous can apply a changest [3] to a copy of the JDK 7 > langtrools repository and build get a javac supporting this feature. > Otherwise, the change will appear in promoted JDK 7 builds in due > course. [4] > > -Joe > > [1] "Project Coin: Post-Devoxx Update, closures and exception handling," > http://blogs.sun.com/darcy/entry/projec_coin_post_devoxx_closures > > [2] "Improved Exception Handling for Java," > http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000003.html > > [3] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a6f2911a7c55 > > [4] http://download.java.net/jdk7/binaries/ > > > > > > From neal at gafter.com Tue May 4 09:01:15 2010 From: neal at gafter.com (Neal Gafter) Date: Tue, 4 May 2010 09:01:15 -0700 Subject: Multi-catch/final rethrow In-Reply-To: References: <4BDF695C.8000306@oracle.com> <4BE03CEE.1060704@oracle.com> Message-ID: On Tue, May 4, 2010 at 8:42 AM, Stephen Colebourne wrote: > Agreed - that is the perspective from a compiler writer. Its just > "better flow analysis". But most developers don't understand that. > > The new code says "throw", the type it is throwing is "Exception", yet > it isn't declared in the method signature - the exception disappears > into thin air! (at least in the eyes of many devs). > > There be a puzzler here... > That would be interesting. I've yet to see a true puzzler where a source file successfully compiles "unexpectedly". Generally such examples are curiosities but don't interfere with honest software engineering. From jonathan.gibbons at oracle.com Tue May 4 09:04:17 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 04 May 2010 09:04:17 -0700 Subject: Multi-catch/final rethrow In-Reply-To: References: <4BDF695C.8000306@oracle.com> <4BE03CEE.1060704@oracle.com> Message-ID: <4BE04581.60809@oracle.com> Stephen Colebourne wrote: > Agreed - that is the perspective from a compiler writer. Its just > "better flow analysis". But most developers don't understand that. > > The new code says "throw", the type it is throwing is "Exception", yet > it isn't declared in the method signature - the exception disappears > into thin air! (at least in the eyes of many devs). > > There be a puzzler here... > > Stephen > Yes, any change to the language/compiler is sure to puzzle some folk. The trick is to minimize the number of folk who remain puzzled once any new features are explained. -- Jon From jonathan.gibbons at oracle.com Tue May 4 08:27:42 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 04 May 2010 08:27:42 -0700 Subject: Multi-catch/final rethrow In-Reply-To: References: <4BDF695C.8000306@oracle.com> Message-ID: <4BE03CEE.1060704@oracle.com> Stephen, Regarding your example, there is no new syntax involved. If you take your "process" method, change "Exception" to "RuntimeException", and wrap it in a class, you'll find it compiles just fine with JDK 6, so it should not be too unfamiliar even to some of you "old hands". > $ more Test.java > class Test { > > public void process() { > try { > System.out.println("No exception thrown here..."); > } catch (final RuntimeException ex) { > throw ex; > } > } > > } > $ /opt/jdk/1.6.0/bin/javac Test.java > $ The only thing that has changed, as regards your example as written, is that now javac can do better flow analysis of the try block to determine that no checked exceptions can be thrown, and so none need to be listed in the throws clause of the method declaration. -- Jon Stephen Colebourne wrote: > While I'm sure many will welcome these additions, I must be clear that > I find the syntax approach used for final rethrow to be undesirable. > The change that the developer makes (adding 'final') is too subtle and > unconnected to the task at hand. > > It also leads to some odd behaviour (assuming I've understood the spec): > > public void process() { > try { > System.out.println("No exception thrown here..."); > } catch (final Exception ex) { > throw ex; > } > } > > Here, we throw an exception without it appearing in the throws clause > of the method. I'm of the opinion that will be pretty confusing to > newcomers (and even some of us old-hands). > > Note that I don't have a great alternative. I suspect a 'rethrow' > keyword would probably be best (dovetailed with the 'final' part for > obvious reasons). Given that we can't use a new keyword, perhaps the > 'throws final' might work. > > Stephen > > > On 4 May 2010 01:25, wrote: > >> Greetings, >> >> As alluded to as a possibility previously [1], I'm happy to announce >> that improved exception handling with multi-catch and final rethrow will >> be part of an upcoming JDK 7 build. Improved exception handling is >> joining other Project Coin features implemented in the repository after >> successful experiences with a multi-catch implementation developed by >> Maurizio Cimadamore. >> >> Maurizio's work also revealed and corrected a flaw in the originally >> proposed static analysis for the set of exception that can be rethrown [2]: >> >> >>> [a] final catch parameter is treated as throwing precisely those >>> exception types that >>> - the try block can throw, >>> - no previous catch clause handles, and >>> - is a subtype of one of the types in the declaration of the catch >>> parameter >>> >> Consider a final rethrow statement as below where the dynamic class of a >> thrown exception differs from the static type (due to a cast in this case): >> >> class Neg04 { >> static class A extends Exception {} >> static class B extends Exception {} >> >> void test(boolean b1, boolean b2) throws B { >> try { >> if (b1) { >> throw new A(); >> } else if (b2) { >> throw new B(); >> } else { >> throw (Throwable)new Exception(); >> } >> } >> catch (A e) {} >> catch (final Exception e) { >> throw e; >> } >> catch (Throwable t) {} >> } >> } >> >> The set of exceptions thrown by the try block is computed {A, B, >> Throwable}; therefore, the set of exceptions that can be rethrown is the >> set of exceptions from the try block: >> >> * minus A, handled by a previous catch clause, giving {B, Throwable} >> * minus Throwable since Throwable is not a subtype of one of the types >> declared for the catch parameter (just Exception in this case), leaving >> just {B} >> >> However, if an Exception is thrown from the try it should be caught in >> the "catch(final Exception e)" clause even if the exception is cast to >> Throwable since catch clauses work based on the runtime class of the >> exceptions being thrown. >> >> To address this, the third clause is changed to >> >> >>> - is a subtype/supertype of one of the types in the declaration of the >>> catch parameter >>> >> More formally, this clause covers computing a join over the set of >> thrown exceptions, eliminating subtypes. In the example above >> {Throwable} is computed as the set of exceptions being throwable from >> the try block. This is then intersected with the exceptions that can be >> caught by the try block, resulting in {Exception}, a properly sound result. >> >> Very general exception types being thrown by a try block would reduce >> the utility of multi-catch since only imprecise information would be >> available. Fortunately, from analyzing the JDK sources, throwing a >> statically imprecise exception seems rare, indicating multi-catch with >> the amended specification should still be very be helpful in practice. >> >> Today the adventurous can apply a changest [3] to a copy of the JDK 7 >> langtrools repository and build get a javac supporting this feature. >> Otherwise, the change will appear in promoted JDK 7 builds in due >> course. [4] >> >> -Joe >> >> [1] "Project Coin: Post-Devoxx Update, closures and exception handling," >> http://blogs.sun.com/darcy/entry/projec_coin_post_devoxx_closures >> >> [2] "Improved Exception Handling for Java," >> http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000003.html >> >> [3] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a6f2911a7c55 >> >> [4] http://download.java.net/jdk7/binaries/ >> >> >> > > From jonathan.gibbons at oracle.com Tue May 4 18:24:21 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 04 May 2010 18:24:21 -0700 Subject: hg: jdk7/tl/langtools: 6943289: Project Coin: Improved Exception Handling for Java (aka 'multicatch') In-Reply-To: References: <20100504001446.C42B544D11@hg.openjdk.java.net> Message-ID: <4BE0C8C5.1070002@oracle.com> Neal, Thank you for your feedback. I am sure we will be able to address your concerns before JDK 7 finally ships. -- Jon Neal Gafter wrote: > This will serve as a code review > > "Disjoint" is not a correct name. The word you should be looking for > is "Disjunct". The code as written allows types that are not disjoint > (such as "Exception | IOException"). It also allows repeated types > (such as "Exception | Exception"). This (name issue) will be more > important if this concept is extended to support exception > transparency in project lambda. In that case the disjuncts are not > necessarily disjoint, especially in the presence of (exception) type > parameters. > > The phrase "multi-catch statement" appears in one of the diagnostics, > but the multi-catch form is not a statement. > > I would have appreciated a chance to review this code before it was > pushed to the langtools repository. Still, you should be > congratulated for getting this submitted under the wire before the > final langtools integration (5/21) preceding jdk7 feature-complete. > > On Mon, May 3, 2010 at 5:14 PM, > wrote: > > Changeset: a6f2911a7c55 > Author: mcimadamore > Date: 2010-05-03 17:12 -0700 > URL: > http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a6f2911a7c55 > > 6943289: Project Coin: Improved Exception Handling for Java (aka > 'multicatch') > Reviewed-by: jjg, darcy > > + src/share/classes/com/sun/source/tree/DisjointTypeTree.java > ! src/share/classes/com/sun/source/tree/Tree.java > ! src/share/classes/com/sun/source/tree/TreeVisitor.java > ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java > ! src/share/classes/com/sun/source/util/TreeScanner.java > ! src/share/classes/com/sun/tools/javac/code/Flags.java > ! src/share/classes/com/sun/tools/javac/code/Source.java > ! src/share/classes/com/sun/tools/javac/comp/Attr.java > ! src/share/classes/com/sun/tools/javac/comp/Flow.java > ! src/share/classes/com/sun/tools/javac/jvm/Gen.java > ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java > ! src/share/classes/com/sun/tools/javac/resources/compiler.properties > ! src/share/classes/com/sun/tools/javac/tree/JCTree.java > ! src/share/classes/com/sun/tools/javac/tree/Pretty.java > ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java > ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java > ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java > ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java > ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java > + test/tools/javac/multicatch/Neg01.java > + test/tools/javac/multicatch/Neg01.out > + test/tools/javac/multicatch/Neg02.java > + test/tools/javac/multicatch/Neg02.out > + test/tools/javac/multicatch/Neg03.java > + test/tools/javac/multicatch/Neg03.out > + test/tools/javac/multicatch/Neg04.java > + test/tools/javac/multicatch/Neg04.out > + test/tools/javac/multicatch/Pos01.java > + test/tools/javac/multicatch/Pos02.java > + test/tools/javac/multicatch/Pos03.java > + test/tools/javac/multicatch/Pos04.java > + test/tools/javac/multicatch/Pos05.java > > From pbenedict at apache.org Thu May 6 10:18:26 2010 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 6 May 2010 12:18:26 -0500 Subject: Multi-catch/final rethrow Message-ID: Joe, I was looking at your explanation >> However, if an Exception is thrown from the try block it should be caught >> in the "catch(final Exception e)" clause even if the exception is cast to >> Throwable since catch clauses work based on the runtime class of the >> exceptions being thrown. The method is declared to only throw checked exception B. According to your explanation, the "(Throwable)new Exception()" is caught by "final Exception e" handler and re-throws -- but it's not of type B. Isn't this an error? Paul From neal at gafter.com Thu May 6 10:50:21 2010 From: neal at gafter.com (Neal Gafter) Date: Thu, 6 May 2010 10:50:21 -0700 Subject: Multi-catch/final rethrow In-Reply-To: References: Message-ID: On Thu, May 6, 2010 at 10:18 AM, Paul Benedict wrote: > Joe, > > I was looking at your explanation > >> However, if an Exception is thrown from the try block it should be > caught > >> in the "catch(final Exception e)" clause even if the exception is cast > to > >> Throwable since catch clauses work based on the runtime class of the > >> exceptions being thrown. > > The method is declared to only throw checked exception B. According to > your explanation, the "(Throwable)new Exception()" is caught by "final > Exception e" handler and re-throws -- but it's not of type B. > > Isn't this an error? > Paul- This should be an error. That's why the correction Joe discussed was made to the spec. The original spec allowed this program without error. Cheers, Neal From Ulf.Zibis at gmx.de Thu May 6 12:45:11 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 06 May 2010 21:45:11 +0200 Subject: Multi-catch/final rethrow In-Reply-To: <4BDFE922.3060805@gmx.de> References: <4BDF695C.8000306@oracle.com> <4BDFE922.3060805@gmx.de> Message-ID: <4BE31C47.3070108@gmx.de> No answer for my questions? :-( -Ulf Am 04.05.2010 11:30, schrieb Ulf Zibis: > Am 04.05.2010 02:25, schrieb joe.darcy at oracle.com: > >> Greetings, >> >> As alluded to as a possibility previously [1], I'm happy to announce >> that improved exception handling with multi-catch and final rethrow will >> be part of an upcoming JDK 7 build. >> >> > Great! > > >> } else { >> throw (Throwable)new Exception(); >> >> > I'm wondering that a cast to a throw is valid syntax, or _in other > words_, what should such a syntax be good for ??? > In fact, an Exception instance is thrown, and should be caught by catch > (Exception e). Or not ? > > > >> To address this, the third clause is changed to >> >> >> >>> - is a subtype/supertype of one of the types in the declaration of the >>> catch parameter >>> >>> > Does that mean, that following variation wouldn't rethrow > Exception("b3") (and (Throwable)new Exception() too?), > as it is nor subtype nor supertype of Exception, as it is itself ? > That IMO would be weird syntax. > > class Neg04 { > static class A extends Exception {} > static class B extends Exception {} > > void test(boolean b1, boolean b2, boolean b3) throws B { > try { > if (b1) { > throw new A(); > } else if (b2) { > throw new B(); > } else if (b3) { > throw new Exception("b3"); > } else { > throw (Throwable)new Exception(); > } > } > catch (A e) {} > catch (final Exception e) { > throw e; > } > catch (Throwable t) {} > } > } > > > -Ulf > > > > > From howard.lovatt at gmail.com Fri May 7 16:16:33 2010 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Sat, 8 May 2010 09:16:33 +1000 Subject: Multi-catch/final rethrow Message-ID: <913AAB0D-281B-4BCF-A62A-27BE60BCA69D@gmail.com> > No answer for my questions? :-( > > -Ulf You might write a method that returns the Throwable: throw message(); Where message is declared as a Throwable, the most general case, but is in fact an Exception. I think the use of cast was only meant to illustrate the wider problem. Am 04.05.2010 11:30, schrieb Ulf Zibis: > Am 04.05.2010 02:25, schrieb joe.darcy at oracle.com: > >> Greetings, >> >> As alluded to as a possibility previously [1], I'm happy to announce >> that improved exception handling with multi-catch and final rethrow will >> be part of an upcoming JDK 7 build. >> >> > Great! > > >> } else { >> throw (Throwable)new Exception(); >> >> > I'm wondering that a cast to a throw is valid syntax, or _in other > words_, what should such a syntax be good for ??? > In fact, an Exception instance is thrown, and should be caught by catch > (Exception e). Or not ? > > > >> To address this, the third clause is changed to >> >> >> >>> - is a subtype/supertype of one of the types in the declaration of the >>> catch parameter >>> >>> > Does that mean, that following variation wouldn't rethrow > Exception("b3") (and (Throwable)new Exception() too?), > as it is nor subtype nor supertype of Exception, as it is itself ? > That IMO would be weird syntax. > > class Neg04 { > static class A extends Exception {} > static class B extends Exception {} > > void test(boolean b1, boolean b2, boolean b3) throws B { > try { > if (b1) { > throw new A(); > } else if (b2) { > throw new B(); > } else if (b3) { > throw new Exception("b3"); > } else { > throw (Throwable)new Exception(); > } > } > catch (A e) {} > catch (final Exception e) { > throw e; > } > catch (Throwable t) {} > } > } > > > -Ulf > > > > > -- Howard Lovatt +61 419 971 263 (sent from my PDA) From joe.darcy at oracle.com Fri May 7 16:26:03 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 07 May 2010 16:26:03 -0700 Subject: Multi-catch/final rethrow In-Reply-To: <4BE31C47.3070108@gmx.de> References: <4BDF695C.8000306@oracle.com> <4BDFE922.3060805@gmx.de> <4BE31C47.3070108@gmx.de> Message-ID: <4BE4A18B.5050308@oracle.com> If you have a question on what is today legal syntax, your friendly neighborhood java compiler can help you answer that question :-) -Joe On 5/6/2010 12:45 PM, Ulf Zibis wrote: > No answer for my questions? :-( > > -Ulf > > > Am 04.05.2010 11:30, schrieb Ulf Zibis: >> Am 04.05.2010 02:25, schrieb joe.darcy at oracle.com: >> >>> Greetings, >>> >>> As alluded to as a possibility previously [1], I'm happy to announce >>> that improved exception handling with multi-catch and final rethrow >>> will >>> be part of an upcoming JDK 7 build. >>> >>> >> Great! >> >> >>> } else { >>> throw (Throwable)new Exception(); >>> >>> >> I'm wondering that a cast to a throw is valid syntax, or _in other >> words_, what should such a syntax be good for ??? >> In fact, an Exception instance is thrown, and should be caught by catch >> (Exception e). Or not ? >> >> >> >>> To address this, the third clause is changed to >>> >>> >>> >>>> - is a subtype/supertype of one of the types in the declaration of the >>>> catch parameter >>>> >>>> >> Does that mean, that following variation wouldn't rethrow >> Exception("b3") (and (Throwable)new Exception() too?), >> as it is nor subtype nor supertype of Exception, as it is itself ? >> That IMO would be weird syntax. >> >> class Neg04 { >> static class A extends Exception {} >> static class B extends Exception {} >> >> void test(boolean b1, boolean b2, boolean b3) throws B { >> try { >> if (b1) { >> throw new A(); >> } else if (b2) { >> throw new B(); >> } else if (b3) { >> throw new Exception("b3"); >> } else { >> throw (Throwable)new Exception(); >> } >> } >> catch (A e) {} >> catch (final Exception e) { >> throw e; >> } >> catch (Throwable t) {} >> } >> } >> >> >> -Ulf >> >> >> >> >> > From Ulf.Zibis at gmx.de Fri May 7 16:36:17 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 08 May 2010 01:36:17 +0200 Subject: Multi-catch/final rethrow In-Reply-To: <4BE4A18B.5050308@oracle.com> References: <4BDF695C.8000306@oracle.com> <4BDFE922.3060805@gmx.de> <4BE31C47.3070108@gmx.de> <4BE4A18B.5050308@oracle.com> Message-ID: <4BE4A3F1.6080505@gmx.de> Howard, Joe, hm, and what's about my 2nd question ? -Ulf Am 08.05.2010 01:26, schrieb joe.darcy at oracle.com: > If you have a question on what is today legal syntax, your friendly > neighborhood java compiler can help you answer that question :-) > > -Joe > > On 5/6/2010 12:45 PM, Ulf Zibis wrote: >> No answer for my questions? :-( >> >> -Ulf >> >> >> Am 04.05.2010 11:30, schrieb Ulf Zibis: >>> Am 04.05.2010 02:25, schrieb joe.darcy at oracle.com: >>>> Greetings, >>>> >>>> As alluded to as a possibility previously [1], I'm happy to announce >>>> that improved exception handling with multi-catch and final rethrow >>>> will >>>> be part of an upcoming JDK 7 build. >>>> >>> Great! >>> >>>> } else { >>>> throw (Throwable)new Exception(); >>>> >>> I'm wondering that a cast to a throw is valid syntax, or _in other >>> words_, what should such a syntax be good for ??? >>> In fact, an Exception instance is thrown, and should be caught by catch >>> (Exception e). Or not ? >>> >>> >>>> To address this, the third clause is changed to >>>> >>>> >>>>> - is a subtype/supertype of one of the types in the declaration of >>>>> the >>>>> catch parameter >>>>> >>> Does that mean, that following variation wouldn't rethrow >>> Exception("b3") (and (Throwable)new Exception() too?), >>> as it is nor subtype nor supertype of Exception, as it is itself ? >>> That IMO would be weird syntax. >>> >>> class Neg04 { >>> static class A extends Exception {} >>> static class B extends Exception {} >>> >>> void test(boolean b1, boolean b2, boolean b3) throws B { >>> try { >>> if (b1) { >>> throw new A(); >>> } else if (b2) { >>> throw new B(); >>> } else if (b3) { >>> throw new Exception("b3"); >>> } else { >>> throw (Throwable)new Exception(); >>> } >>> } >>> catch (A e) {} >>> catch (final Exception e) { >>> throw e; >>> } >>> catch (Throwable t) {} >>> } >>> } >>> >>> >>> -Ulf >>> >>> >>> >>> >> > > From neal at gafter.com Fri May 7 17:01:01 2010 From: neal at gafter.com (Neal Gafter) Date: Fri, 7 May 2010 17:01:01 -0700 Subject: Multi-catch/final rethrow In-Reply-To: <4BE4A3F1.6080505@gmx.de> References: <4BDF695C.8000306@oracle.com> <4BDFE922.3060805@gmx.de> <4BE31C47.3070108@gmx.de> <4BE4A18B.5050308@oracle.com> <4BE4A3F1.6080505@gmx.de> Message-ID: Ulf- to your 2nd question: Exception is both a supertype and a subtype of Exception. See JLS 4.10, and note the word "reflexive". Cheers, Neal On Fri, May 7, 2010 at 4:36 PM, Ulf Zibis wrote: > Howard, Joe, > > hm, and what's about my 2nd question ? > > -Ulf > > > Am 08.05.2010 01:26, schrieb joe.darcy at oracle.com: > > If you have a question on what is today legal syntax, your friendly > > neighborhood java compiler can help you answer that question :-) > > > > -Joe > > > > On 5/6/2010 12:45 PM, Ulf Zibis wrote: > >> No answer for my questions? :-( > >> > >> -Ulf > >> > >> > >> Am 04.05.2010 11:30, schrieb Ulf Zibis: > >>> Am 04.05.2010 02:25, schrieb joe.darcy at oracle.com: > >>>> Greetings, > >>>> > >>>> As alluded to as a possibility previously [1], I'm happy to announce > >>>> that improved exception handling with multi-catch and final rethrow > >>>> will > >>>> be part of an upcoming JDK 7 build. > >>>> > >>> Great! > >>> > >>>> } else { > >>>> throw (Throwable)new Exception(); > >>>> > >>> I'm wondering that a cast to a throw is valid syntax, or _in other > >>> words_, what should such a syntax be good for ??? > >>> In fact, an Exception instance is thrown, and should be caught by catch > >>> (Exception e). Or not ? > >>> > >>> > >>>> To address this, the third clause is changed to > >>>> > >>>> > >>>>> - is a subtype/supertype of one of the types in the declaration of > >>>>> the > >>>>> catch parameter > >>>>> > >>> Does that mean, that following variation wouldn't rethrow > >>> Exception("b3") (and (Throwable)new Exception() too?), > >>> as it is nor subtype nor supertype of Exception, as it is itself ? > >>> That IMO would be weird syntax. > >>> > >>> class Neg04 { > >>> static class A extends Exception {} > >>> static class B extends Exception {} > >>> > >>> void test(boolean b1, boolean b2, boolean b3) throws B { > >>> try { > >>> if (b1) { > >>> throw new A(); > >>> } else if (b2) { > >>> throw new B(); > >>> } else if (b3) { > >>> throw new Exception("b3"); > >>> } else { > >>> throw (Throwable)new Exception(); > >>> } > >>> } > >>> catch (A e) {} > >>> catch (final Exception e) { > >>> throw e; > >>> } > >>> catch (Throwable t) {} > >>> } > >>> } > >>> > >>> > >>> -Ulf > >>> > >>> > >>> > >>> > >> > > > > > > > From Ulf.Zibis at gmx.de Fri May 7 17:33:08 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 08 May 2010 02:33:08 +0200 Subject: Multi-catch/final rethrow In-Reply-To: References: <4BDF695C.8000306@oracle.com> <4BDFE922.3060805@gmx.de> <4BE31C47.3070108@gmx.de> <4BE4A18B.5050308@oracle.com> <4BE4A3F1.6080505@gmx.de> Message-ID: <4BE4B144.3080401@gmx.de> Thanks, where can I find JLS 4.10 ? Doc of JDK 7 b84 only links to http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html -Ulf Am 08.05.2010 02:01, schrieb Neal Gafter: > Ulf- > > to your 2nd question: Exception is both a supertype and a subtype of > Exception. See JLS 4.10, and note the word "reflexive". > > Cheers, > Neal > > On Fri, May 7, 2010 at 4:36 PM, Ulf Zibis > wrote: > > Howard, Joe, > > hm, and what's about my 2nd question ? > > -Ulf > > > Am 08.05.2010 01:26, schrieb joe.darcy at oracle.com > : > > If you have a question on what is today legal syntax, your friendly > > neighborhood java compiler can help you answer that question :-) > > > > -Joe > > > > On 5/6/2010 12:45 PM, Ulf Zibis wrote: > >> No answer for my questions? :-( > >> > >> -Ulf > >> > >> > >> Am 04.05.2010 11:30, schrieb Ulf Zibis: > >>> Am 04.05.2010 02:25, schrieb joe.darcy at oracle.com > : > >>>> Greetings, > >>>> > >>>> As alluded to as a possibility previously [1], I'm happy to > announce > >>>> that improved exception handling with multi-catch and final > rethrow > >>>> will > >>>> be part of an upcoming JDK 7 build. > >>>> > >>> Great! > >>> > >>>> } else { > >>>> throw (Throwable)new Exception(); > >>>> > >>> I'm wondering that a cast to a throw is valid syntax, or _in other > >>> words_, what should such a syntax be good for ??? > >>> In fact, an Exception instance is thrown, and should be caught > by catch > >>> (Exception e). Or not ? > >>> > >>> > >>>> To address this, the third clause is changed to > >>>> > >>>> > >>>>> - is a subtype/supertype of one of the types in the > declaration of > >>>>> the > >>>>> catch parameter > >>>>> > >>> Does that mean, that following variation wouldn't rethrow > >>> Exception("b3") (and (Throwable)new Exception() too?), > >>> as it is nor subtype nor supertype of Exception, as it is itself ? > >>> That IMO would be weird syntax. > >>> > >>> class Neg04 { > >>> static class A extends Exception {} > >>> static class B extends Exception {} > >>> > >>> void test(boolean b1, boolean b2, boolean b3) throws B { > >>> try { > >>> if (b1) { > >>> throw new A(); > >>> } else if (b2) { > >>> throw new B(); > >>> } else if (b3) { > >>> throw new Exception("b3"); > >>> } else { > >>> throw (Throwable)new Exception(); > >>> } > >>> } > >>> catch (A e) {} > >>> catch (final Exception e) { > >>> throw e; > >>> } > >>> catch (Throwable t) {} > >>> } > >>> } > >>> > >>> > >>> -Ulf > >>> > >>> > >>> > >>> > >> > > > > > > > From neal at gafter.com Fri May 7 17:58:02 2010 From: neal at gafter.com (Neal Gafter) Date: Fri, 7 May 2010 17:58:02 -0700 Subject: Multi-catch/final rethrow In-Reply-To: <4BE4B144.3080401@gmx.de> References: <4BDF695C.8000306@oracle.com> <4BDFE922.3060805@gmx.de> <4BE31C47.3070108@gmx.de> <4BE4A18B.5050308@oracle.com> <4BE4A3F1.6080505@gmx.de> <4BE4B144.3080401@gmx.de> Message-ID: On Fri, May 7, 2010 at 5:33 PM, Ulf Zibis wrote: > Thanks, where can I find JLS 4.10 ? > I meant section 4.10: http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.10 From Ulf.Zibis at gmx.de Sat May 8 14:53:27 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 08 May 2010 23:53:27 +0200 Subject: Multi-catch/final rethrow In-Reply-To: References: <4BDF695C.8000306@oracle.com> <4BDFE922.3060805@gmx.de> <4BE31C47.3070108@gmx.de> <4BE4A18B.5050308@oracle.com> <4BE4A3F1.6080505@gmx.de> Message-ID: <4BE5DD57.10401@gmx.de> So each type is subtype and supertype of itself ? Thanks for clarification. -Ulf Am 08.05.2010 02:01, schrieb Neal Gafter: > Ulf- > > to your 2nd question: Exception is both a supertype and a subtype of > Exception. See JLS 4.10, and note the word "reflexive". > > Cheers, > Neal > > On Fri, May 7, 2010 at 4:36 PM, Ulf Zibis > wrote: > > Howard, Joe, > > hm, and what's about my 2nd question ? > > -Ulf > > > Am 08.05.2010 01:26, schrieb joe.darcy at oracle.com > : > > If you have a question on what is today legal syntax, your friendly > > neighborhood java compiler can help you answer that question :-) > > > > -Joe > > > > On 5/6/2010 12:45 PM, Ulf Zibis wrote: > >> No answer for my questions? :-( > >> > >> -Ulf > >> > >> > >> Am 04.05.2010 11:30, schrieb Ulf Zibis: > >>> Am 04.05.2010 02:25, schrieb joe.darcy at oracle.com > : > >>>> Greetings, > >>>> > >>>> As alluded to as a possibility previously [1], I'm happy to > announce > >>>> that improved exception handling with multi-catch and final > rethrow > >>>> will > >>>> be part of an upcoming JDK 7 build. > >>>> > >>> Great! > >>> > >>>> } else { > >>>> throw (Throwable)new Exception(); > >>>> > >>> I'm wondering that a cast to a throw is valid syntax, or _in other > >>> words_, what should such a syntax be good for ??? > >>> In fact, an Exception instance is thrown, and should be caught > by catch > >>> (Exception e). Or not ? > >>> > >>> > >>>> To address this, the third clause is changed to > >>>> > >>>> > >>>>> - is a subtype/supertype of one of the types in the > declaration of > >>>>> the > >>>>> catch parameter > >>>>> > >>> Does that mean, that following variation wouldn't rethrow > >>> Exception("b3") (and (Throwable)new Exception() too?), > >>> as it is nor subtype nor supertype of Exception, as it is itself ? > >>> That IMO would be weird syntax. > >>> > >>> class Neg04 { > >>> static class A extends Exception {} > >>> static class B extends Exception {} > >>> > >>> void test(boolean b1, boolean b2, boolean b3) throws B { > >>> try { > >>> if (b1) { > >>> throw new A(); > >>> } else if (b2) { > >>> throw new B(); > >>> } else if (b3) { > >>> throw new Exception("b3"); > >>> } else { > >>> throw (Throwable)new Exception(); > >>> } > >>> } > >>> catch (A e) {} > >>> catch (final Exception e) { > >>> throw e; > >>> } > >>> catch (Throwable t) {} > >>> } > >>> } > >>> > >>> > >>> -Ulf > >>> > >>> > >>> > >>> > >> > > > > > > >