Checked Exceptions do not exist on the JVM.

[Reinier Zwitserloot]

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.

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