the possibly thrown exception types of
the corresponding try block.
Here, the nested try block is understood to be throwing an exception of
type SomeRootException, but this is
imprecise, because in reality, it is of type
SomeChildException. Nevertheless, the
catch block on SomeOtherChildException
is allowed under those semantics.
By contrast, the code in Listing 16 does
not compile with Java SE 7 because a
precise analysis of the rethrown types is
performed, as shown in Listing 17.
The exception type analysis works
as follows:
■ ■ The first try blocks can throw
an exception only of type
SomeChildException.
■ ■ firstException is effectively final
because it is not modified in the
catch block.
■ ■ The compiler knows that firstException
is actually of type SomeChildException,
thanks to its being final.
■ ■ When firstException is rethrown, the
compiler is aware that it is precisely of
type SomeChildException and, hence,
the try block is understood to throw
only SomeChildException exceptions
just like the topmost try block.
■ ■ The catch(SomeOtherChildException
secondException) expression is invalid
because no corresponding try blocks
can throw it or a subtype of it.
The introduction of the multi-catch
statement is not just beneficial for the
purpose of making the Java language
more concise, because its implementation required improving the exception
type analysis.
static class SomeRootException extends Exception { }
static class SomeChildException extends SomeRootException { }
static class SomeOtherChildException extends SomeRootException { }
public static void main(String... args) throws Throwable {
try {
throw new SomeChildException();
} catch (SomeRootException firstException) {
try {
throw firstException;
JAVA IN ACTION
GIVE BACK!
ADOPT A JSR
Download all listings in this issue as text
Find your JSR here
Nevertheless, this change can break
the compilation of existing source code,
because the more precise exception
type analysis can report errors as in the
example provided in Listing 17. The decision to “go for it” was taken after examining millions of lines of existing Java
code and realizing that such settings
were extremely rare.
rather than massive changes, we can
expect them to be a strong argument in
favor of a rapid adoption of the Java SE 7
platform. </article>
ABOUT US
Conclusion
This article concludes a two-part series
dedicated to describing the evolution
of the Java language in Java SE 7. The
changes allow writing more-concise
and safer code while not breaking backward compatibility with existing Java
code. Because the changes are subtle
yet appealing touches to the language,
LEARN MORE
•;Project Coin mailing-list archives
•;Project Coin blogs
•;Latest maintenance review of the Java
Language Specification
•;“Language Designer’s Notebook:
Quantitative Language Design”
•;“Project Coin: Inducing Contributory
Heap Pollution”
•;“Project Coin: Safe Varargs”
•;“Project Coin: Improving Multi-Catch and
More Precise Rethrow”
