Checked Exceptions do not exist on the JVM.

[Reinier Zwitserloot]

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.


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.

I'm specifically NOT proposing to destroy the building - that would be  
'Let's get rid of checked exceptions' altogether.


  --Reinier Zwitserloot



On May 20, 2009, at 15:47, Ruslan Shevchenko wrote:

>> Ruslan, you've got it all wrong. Though, you've just proved to this
>> list that java programmers don't really get this concept, which is  
>> one
>> of the reasons why I want to introduce it: Make it obvious to java
>> programmers that the JVM does *NOT* guarantee that checked exceptions
>> are declared.
>>
>>  Checked exceptions do not exist.
>>
>> That's right. They don't. There's no such thing. It's all a figment  
>> of
>> javac. The JVM does not have checked exceptions. All it knows about  
>> is
>> 'throws clauses', which are part of a method's signature and have  
>> ZERO
>> impact on how a JVM runs a class file. As far as the JVM is  
>> concerned,
>> throws clauses are just a comment. Utterly ignored by javac. You can
>> strip every single one out of every class file and run an app, and  
>> the
>> execution of it would be 100% the same. The only change would be in
>> java.lang.reflect's getExceptionTypes() method.
>>
>
> What means 'really' ?
> Can we say, that ... for examples,  'for' construct does not exists,
> because it emulated by 'if-s' on JVM level ?
>
>>
>> In other words: There is *NO* guarantee whatsoever in the JVM that
>> checked exceptions can only occur in situations where they are
>> explicitly declared. If your code relies on it, then your code is  
>> buggy.
>>
>
> Java (as language) give me some isolation level. Of course not 100%,
> (Class.newInstance() is a hole.
> //I misread documentation, because I was not able to imagine that such
> //hole exists (!).
> But you propose to destroy building because exists one hole,
> instead fixing building ? Better fix - is declare  
> Class.newInstance() to
> throw Throwable.
>
> Can I ask community:
>   anybody know, why such situation exists and reason not to fix
> Class.newInstance() ?
>
>
>>
>> Thirdly, you misunderstand what my ignoreslist proposal does: It does
>> not silently swallow the exception, that'd be a very stupid way of
>> handling exceptions that you don't -think- can occur. An ignoreslist
>
> Yes, (I wrote this in my next letter).
> // word 'ignore' fooled me and will fool others.
> Let's speak 'not-care' instead 'ignore'
>
> So
> int f()  not-care MyException
> {
>
> }
>
> will throw MyException, which will be not handled for JVM, for  
> programmer
> this mean, that this code:
>
> 1. will throw LinkageError, when f is not called inside some try  
> blocks,
> where MyException is not catched.
> 2. will throw MyException, when f is called inside some try blocks,  
> where
> MyException (or generic Exception or Throwable) is cathed.
>
>
>>
>> You're also mistaken in retrofitting Runnable with 'throws  
>> Exception':
>> That'll break many thousands of classes out there in real life. You
>> forget that people don't just make Runnables and hand them off to
>> java.lang.Thread; there's plenty of code out there that *receives*
>> Runnables, and that code presumes that its run() method does not  
>> throw
>> any checked exceptions. It would be backwards compatible (because, as
>> I said, the JVM doesn't know about these things), but it wouldn't be
>
> // Hmm, looks like my next letter was not in list. (in which I  
> correct self
> //in this points)
> //I guess 1.6 -> 1.7 transition can break API compatibility: it's  
> major
> //revision change.
>
> Java (as language) support *both* checked and unchecked exception.
> More realistic approach for transition 'all exceptions unchecked' is
> change API to throw unchecked exception. (Which we see on practice in
> layered software system, and where rethrow proposal good for).
>
>
>
>