Getting rid of Try.FatalException and Try.NonFatalException by "sneaky throwing"

[danieldietrich]

It is possible to throw every type of exception as unchecked exception:

static void testSneaky() {
  final Exception e = new Exception();
  sneakyThrow(e);    //no problems here
}

@SuppressWarnings("unchecked")
static <T extends Throwable> void sneakyThrow(Throwable t) throws T {
  throw (T) t;
}

(Found on StackOverflow)

• Therefore we are able to get rid of our exception wrappers Try.FatalException and Try.NonFatalException.
• Additionally we should rethink CheckedFunction*.unchecked() and API.Unchecked(*)

[danieldietrich]

Using sneaky throw might lead to and UndeclaredThrowableException when used in conjunction with dynamic proxies.

Example:

import java.lang.reflect.Proxy;

public class Test {

    public static void main(String[] args) throws Throwable {
        new Test().run();
    }

    void run() throws Throwable {
        
        I obj = (I) Proxy.newProxyInstance(
                Test.class.getClassLoader(),
                new Class<?>[] { I.class },
                (proxy, method, args) -> sneakyThrow(new Exception("test")));
        
        // This call throws java.lang.reflect.UndeclaredThrowableException.
        // It could be fixed if I.test() declares 'throws Exception'.
        // Throwing a RuntimeException does not lead to a UndeclaredThrowableException.
        obj.test();
    }

    interface I {
        void test() /* throws Exception */;
    }

    @SuppressWarnings("unchecked")
    static <T extends Throwable, R> R sneakyThrow(Throwable t) throws T {
        throw (T) t;
    }

}

We should state that in the javadoc when changing Try.get() (which will re-throw the cause in the case of a Failure).

[ravn]

You should not use sneaky throws as it wrecks the Java design, and is highly frowned upon by the Java architect(s?).

[danieldietrich]

Yes, it introduces new problems, like the UndeclaredThrowableException...

[chb0github]

The java "architects" should never have introduced checked exceptions into the compiler - exceptions are not checked in the VM - which is why scala/kotlin can run on the JVM and not have any at all.

If using sneaky throws can introduce an essentially unrecoverable problem then, sadly, it must be excluded. If excluding it means uglier code ... well, welcome to Java. It's a risky proposition in a library

Just my .02$ -

[ravn]

Please revert to proper handling. It can most likely be done simply by storing the exception in a Throwable (without having looked at the code) and moving forward.

[danieldietrich]

@ravn yes, that seems to be the only solution in order to offer a library with predictable behavior.

I created a new issue: #2049