问题
Can someone explain this code?
public class SneakyThrow {
public static void sneakyThrow(Throwable ex) {
SneakyThrow.<RuntimeException>sneakyThrowInner(ex);
}
private static <T extends Throwable> T sneakyThrowInner(Throwable ex) throws T {
throw (T) ex;
}
public static void main(String[] args) {
SneakyThrow.sneakyThrow(new Exception());
}
}
It may seems strange, but this doesn\'t produce a cast exception, and permits to throw a checked exception without having to declare it in the signature, or to wrap it in an unchecked exception.
Notice that neither sneakyThrow(...) or the main are declaring any checked exception, but the output is:
Exception in thread \"main\" java.lang.Exception
at com.xxx.SneakyThrow.main(SneakyThrow.java:20)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
This hack is used in Lombok, with the annotation @SneakyThrow, which permits to throw checked exceptions without declaring them.
I know it has something to do with type erasure, but i\'m not sure to understand every part of the hack.
Edit:
I know that we can insert an Integer in a List<String> and that checked/unchecked exceptions distinction is a compile time feature.
When casting from a non-generic type like List to a generic type like List<XXX> the compiler produces a warning. But it\'s less common to cast to a generic type directly like (T) ex in the above code.
If you want, the part that seems strange for me is that I understand that inside the JVM a List<Dog> and List<Cat> looks the same, but the above code seems to mean that finally we can also assign a value of type Cat to a variable of type Dog or something like that.
回答1:
If you compile it with -Xlint you'll get a warning:
c:\Users\Jon\Test>javac -Xlint SneakyThrow.java
SneakyThrow.java:9: warning: [unchecked] unchecked cast
throw (T) ex;
^
required: T
found: Throwable
where T is a type-variable:
T extends Throwable declared in method <T>sneakyThrowInner(Throwable)
1 warning
That's basically saying "This cast isn't really checked at execution time" (due to type erasure) - so the compiler reluctantly assumes you're doing the right thing, knowing that it won't actually be checked.
Now it's only the compiler which cares about checked and unchecked exceptions - it's not part of the JVM at all. So once you've got past the compiler, you're home free.
I'd strongly advise you to avoid doing this though.
In many cases there's a "real" check when you're using generics because something uses the desired type - but that's not always the case. For example:
List<String> strings = new ArrayList<String>();
List raw = strings;
raw.add(new Object()); // Haha! I've put a non-String in a List<String>!
Object x = strings.get(0); // This doesn't need a cast, so no exception...
回答2:
he above code seems to mean that finally we can also assign a value of type Cat to a variable of type Dog or something like that.
You have to think in terms of how the classes are structured. T extends Throwable and you are passing Exception to it. This is like assigning Dog to Animal not Dog to Cat.
The compiler has rules about which Throwable are checked and which are not, based on inheritance. These are applied at compile time and it is possible to confuse the compiler into allowing you to throw a check exception. At runtime this has no impact.
Checked exceptions are a compile time feature (like generics)
BTW Throwable is a checked exception as well. If you sub class it, it will be checked unless it is a sub-class of Error or RuntimeException.
Two other way to throw checked exceptions without the compiler being aware that you are doing this.
Thread.currentThread().stop(throwable);
Unsafe.getUnsafe().throwException(throwable);
The only difference is that both use native code.
回答3:
As of Java 8, the sneakyThrowInner helper method is not longer required. sneakyThrow can be written as:
@SuppressWarnings("unchecked")
static <T extends Throwable> RuntimeException sneakyThrow(Throwable t) throws T {
throw (T)t;
}
See the "A peculiar feature of exception type inference in Java 8" post.
The T of sneakyThrow is inferred to be RuntimeException. This can be followed from the langauge spec on type inference (http://docs.oracle.com/javase/specs/jls/se8/html/jls-18.html)
Note: The sneakyThrow function is declared to return RuntimeException, so that it can be used as follows:
int example() {
if (a_problem_occurred) {
throw sneakyThrow(new IOException("An I/O exception occurred"));
// Without the throw here, we'd need a return statement!
} else {
return 42;
}
}
By throwing the RuntimeException returned by sneakyThrow, the Java compiler knows this execution path terminates. (Of course, sneakyThrow itself doesn't return.)
回答4:
Let us look at the code below :
public class SneakyThrow {
public static void sneakyThrow(Throwable ex) {
SneakyThrow.<RuntimeException>sneakyThrowInner(ex);
}
private static <T extends Throwable> T sneakyThrowInner(Throwable ex) throws T {
throw (T) ex;
}
public static void main(String[] args) {
SneakyThrow.sneakyThrow(new Exception());
}
}
Let us see why is it behaving like this.
First of all any cast to a type parameter ignored by compiler. JVM will directly cast it. So, throw (T) ex; will not be checked for type safety by compiler. But, by the time code reaches the JVM , type erasure takes place. Hence code will be like : [Note : Actual code will be byte code . Below is just to explain what type erasure does.]
public class SneakyThrow {
public static void sneakyThrow(Throwable ex) {
SneakyThrow.sneakyThrowInner(ex); // Note : Throwable is checked exception but we don't mention anything here for it
}
private static Throwable sneakyThrowInner(Throwable ex) throws Throwable {
throw (Throwable) ex;
}
public static void main(String[] args) {
SneakyThrow.sneakyThrow(new Exception());
}
}
First thing to note is every thing will run smooth and no ClassCastException will be thrown as JVM is easily able to type cast ex to Throwable.
Second thing to note here is that Compiler always forced us to catch or pass on the checked exception received. No such checks are made by JVM. Here, after we type casted, ideally , SneakyThrow.sneakyThrowInner(ex); should be forced to handle the Throwable exception but remember , the byte code of this version is reached to JVM. Hence, we somehow fooled the compiler.
Do like this :
public class SneakyThrow {
public static void sneakyThrow(Throwable ex) {
SneakyThrow.<RuntimeException>sneakyThrowInner(ex);
}
private static <T extends Throwable> T sneakyThrowInner(Throwable ex) throws T {
throw (T) ex;
}
public static void main(String[] args) {
try {
SneakyThrow.sneakyThrow(new Exception());
}catch (Throwable ex){
System.out.println("Done Succesfully"); // Added to show everything runs fine
}
}
}
Output : Done Succesfully
来源：https://stackoverflow.com/questions/14038649/java-sneakythrow-of-exceptions-type-erasure