NewInstance

As per current Java implementation, if we have an unchecked exception we can't extend it to make a checked one, and if we have a checked exception we can't extend it to make an unchecked one (except for RuntimeException that is unchecked and extends from Exception that is checked).
For sure this limit is wanted by design.

But... what if things were different? What if RuntimeException was a interface instead of a class? Then you could do:

1public class SuperException
2    extends Exception {
3}
4
5public class SubException
6    extends SuperException
7    implements RuntimeException {
8}

So, in my API, if I have a method that can throw SuperException, I can also throw the unchecked SubException; but if my API needs to throw SubException that is a SuperException, I don't need to impose the caller to handle that.

 1public void canThrowSuperException throws SuperException {
 2    ...
 3    if (...) throw new SuperException();
 4    else throw new SubException();
 5    ...
 6}
 7
 8// Don't need to declare SuperException or 
 9// SubException on the signature
10public void canThrowSubException() {
11    ...
12    if (...) throw new SubException();
13    ...
14}
15
16// and in the caller code... 
17// if I catch SuperException I also catch SubException
18
19try {
20      ...
21} catch (SuperException x) {
22    // ex can be instance of SuperException 
23    // ...but also SubException
24}

In this way a checked exception can be extended with unchecked ones, but unchecked exception subclesses can't become checked. Can this be an advantage? Maybe, or maybe not.
Could be very easy to introduce the Unchecked interface into the java core libraries, and make RuntimeException to implement Unchecked and have backward compatibility; then could be easy to change the compiler to handle Unchecked interface instead of RuntimeException for handing unchecked exceptions.

Also, at the moment, the compiler really checks that the catched exceptions can be thrown in the try block:

 1public class Main {
 2    class SuperException extends Exception {
 3
 4    }
 5
 6    class SubException extends SuperException
 7        // implements RuntimeException 
 8    {
 9    }
10
11    void canThrowSub() {
12       // if (...) throw SubException(); 
13    }
14
15    void main() {
16        try {
17            canThrowSub();
18        }
19        catch( SuperException e ) {
20        }
21    }
22}

Giving an error saying that the try block doesn't throw the caught exception. So, if it were possible to uncomment line 7, then this compile checking becomes unnecessary. Sometime checked exception can be thrown also when undeclared, so this compile time check is already inadequate for those cases.

I think that having the possibility to extend checked exception with unchecked ones could be an advantage in some cases. For example, usually I don't want to catch SQLExceptions so I may write an unchecked JDBC driver that throws UncheckedSQLExceptions that could be interface compatible with standard JDBC drivers.