Checked Exceptions do not exist on the JVM.

[Ruslan Shevchenko]

> No, Ruslan, the JVM doesn't do anything special to the exception. It
> remains a MyException - it isn't changed, wrapped, swallowed,
> converted, or anything else.
>
> Again: At the JVM level, you can throw a checked MyException even if
> your method does not specifcally say "throws MyException". The JVM
> ignores 'throws' clauses on method signatures.
>

 It means, they can't do set of optimizations to exception handling, based
on  facts that some functions are exception-free.


> So, either the exception is handled somewhere up the stack by a catch
> block, or if it isn't, then it eventually arrives at the thread
> unhandled exception code, which you can configure on a per-thread
> basis. By default, a thread will dump a stack trace to the console.
>
>   --Reinier Zwitserloot
>
>
>
> On May 21, 2009, at 08:06, Ruslan Shevchenko wrote:
>
>>> Ruslan:
>>>
>>> Why do you keep mentioning LinkageError? I'll try to explain the
>>> 'not-
>>> care' keyword one more time:
>>>
>>> int f() not-care MyException {
>>>     throw MyException();
>>> }
>>>
>>> does the *exact* same thing as:
>>>
>>> int f() throws MyException {
>>>    throw MyException();
>>> }
>>>
>>> The only difference is for javac: In the second case, with the throws
>>> statement, the caller must either wrap their call to f() in a try/
>>> catch block nd catch MyException, -or-, the caller must add a 'throws
>>> MyException' to their method. However, in the not-care case, a caller
>>> does NOT have to do these things. That's all.
>>>
>>
>> I understand what you mean. But after 'that's all' JVM must do
>> something
>> with exception, which was not handled ...  hmm, in theory it can be
>> translated to LinkageError in process barrier.
>>
>> Oops, it was not for plain JVM ;) Plain JVM just do printStackTrace()
>> on exception. (I wrote small text to see this).
>>
>> package x;
>>
>> public class X
>> {
>>
>>  public X() throws Exception
>>  {
>>    throw new Exception("hi!");
>>  }
>>
>>  public static void main(String[] args) {
>>    try {
>>      X x = X.class.newInstance();
>>    } catch (InstantiationException ex) {
>>      System.err.println("instantiation exception");
>>      ex.printStackTrace();
>>    } catch (IllegalAccessException ex) {
>>      System.err.println("illegal access exception");
>>      ex.printStackTrace();
>>    }
>>  }
>>
>> }
>>
>> But I guess this is implementation-specifics property of JVM.   I. e.
>> nothing prevent JVM-implementors to handle unhandled checked
>> exceptions
>> and throw LinkageErrors on some barriers (function or process).
>> And I can imagine optimizations, where such change is necessory.
>>>
>>> Also, we can't add 'throws Throwable' to Class.newInstance - it would
>>> break backwards compatibility. It's also not the only problem - you
>>> can't close the 'construct a class file' hole, and you certainly
>>> can't
>>> close the 'there are other languages that run on the JVM' hole. Java
>>> does not break backwards compatibility. I'll let Joe give the final
>>> word, but the odds that java will add 'throws Throwable' to
>>> Class.newInstance, or adds 'throws Exception' to java.lang.Runnable,
>>> are somewhere  between pigs flying and hell freezing over. It just
>>> won't happen.
>>>
>>
>> Some evolutions exists (i. e. all methods of Date deprecated,
>> ThreadLocal
>> interdace changed a lot). May be changes to Runnable or Threads to
>> radical; but with Class.newInstantce() ...
>>
>> Ok, let's wait for process of library changes. (As I understand, it
>> will
>> be after coin)
>>
>>
>>
>>
>
>