Checked Exceptions do not exist on the JVM.

[Ruslan Shevchenko]

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