Checked Exceptions do not exist on the JVM.

[Reinier Zwitserloot]

The JVM cannot make optimizations in regards to exceptions now,  
either. How often do I need to repeat this:

You can make class files that throw checked exceptions out of a method  
that does not declare it in the throws clause

  --Reinier Zwitserloot



On May 21, 2009, at 08:29, Ruslan Shevchenko wrote:

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