UPDATED: Rethrows Clause

[Ruslan Shevchenko]

>>
>> example:
>>
>> Runnable r = new Runnable() {
>>      public void run() ignores UnsupportedEncodingException {
>>          String x = new String(inBytes, "UTF-8");
>>      }
>> };
>>
>

 Or, you means that ignore will throw LinkageError (?)
But this is near the same as rethrow() and word ignore is not very
intuitive. (If I was fooled, millions of other programmers also will be
fulled;)


>> includes two of them: The fact that runnable throws no checked
>> exceptions is clearly a mistake in regards to threading, because
>> Thread objects clearly should handle ANY exception falling out of its
>> run() method (and it in fact does, via the unchecked exception handler
>> mechanism), and there's a general mismatch between main(), which MAY
>> throw exceptions, and run(), which may not, even though they are both
>> 'thread start points'. Another mistake is
>
>  Adding throw exception to signature of Runnable.run does not broke
> anything in existent code, so this can be nice library change.
>
(it's incorrest. Of course, exists incompatibility, but only for code,
which use Thread or Runnable as parameters: I guess this rare (some deep
libraries), and JDK6->JDK7 transition can allows such incompatibility)

>>
>> NB: For sanity purposes, the restriction on javac that the try block
>> MUST contain at least 1 statement that could throw a checked exception
>> type that is listed on one of the accompanying catch blocks (other
>> than Exception, which you can always catch), should go away; this has
>> already been proposed before, and in fact is a backwards compatibility
>> painpoint for the coin proposal that allows you to rethrow a final
>> Exception as if its type is the intersection of all checked types
>> thrown by the statements in the try body.
>>

 That this is work for RuntimeExceptions. And Java support both runtime
and checked exception. I guess, that transition to unchecked exception
can be done mostly by migrating  libraries from checked exception to
unchecked.

And, may be here we have answer: why framework code have high percentage
of rethrow statements, when application code (such as e-commerce system or
ERP) - not.
 Because on first layer all checked exceptions become runtime; than we work
with runtime exceptions in more simple (and risky) manner