Java SneakyThrow исключений, тип стирания

Если вы скомпилируете его с -Xlint, вы получите предупреждение:

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

Это в основном говорит: «Это приведение не на самом деле проверяется во время выполнения» (из-за стирания типа) — поэтому компилятор неохотно предполагает, что вы делаете правильные вещи, зная, что на самом деле это не будет проверено.

Теперь о проверенных и непроверенных исключениях заботится только компилятор — он вообще не является частью JVM. Итак, как только вы прошли компилятор, вы свободны дома.

Я настоятельно рекомендую вам избегать этого.

Во многих случаях существует "настоящая" проверка, когда вы используете дженерики, потому что что-то использует нужный тип, но всегда так бывает. Например:

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

приведенный выше код, по-видимому, означает, что, наконец, мы также можем присвоить значение типа Cat переменной типа Dog или что-то в этом роде.

Вы должны думать о том, как структурированы классы. T extends Throwable и вы передаете ему Exception. Это все равно, что присвоить Dog Animal, а не Dog Cat.

У компилятора есть правила о том, какие Throwable проверяются, а какие нет, основанные на наследовании. Они применяются во время компиляции, и компилятор может сбить вас с толку, позволяя вам генерировать контрольное исключение. Во время выполнения это не влияет.

Проверенные исключения — это функция времени компиляции (например, дженерики).

Кстати, Throwable также является отмеченным исключением. Если вы подклассируете его, он будет проверен, если только он не является подклассом Error или RuntimeException.

Два других способа генерировать проверенные исключения, когда компилятор не знает, что вы это делаете.

Thread.currentThread().stop(throwable);

Unsafe.getUnsafe().throwException(throwable);

Единственная разница в том, что оба используют собственный код.

Начиная с Java 8 вспомогательный метод sneakyThrowInner больше не требуется. sneakyThrow можно записать как:

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

См. статью Особая особенность вывода типа исключения в Java 8.

Подразумевается, что значение T для snickyThrow является RuntimeException. Об этом можно узнать из спецификации языка по выводу типов (http://docs.oracle.com/javase/specs/jls/se8/html/jls-18.html)

Примечание. Функция sneakyThrow объявлена ​​возвращающей RuntimeException, поэтому ее можно использовать следующим образом:

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;
   }
}

Выбрасывая RuntimeException, возвращаемый sneakyThrow, компилятор Java знает, что этот путь выполнения завершается. (Конечно, сам sneakyThrow не возвращается.)

Давайте посмотрим на код ниже:

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());
  }


}

Давайте посмотрим, почему он так себя ведет.

Во-первых, любое приведение к параметру типа игнорируется компилятором. JVM будет напрямую использовать его. Таким образом, throw (T) ex; не будет проверяться компилятором на безопасность типов. Но к тому времени, когда код достигает JVM, происходит стирание типа. Следовательно, код будет выглядеть так: [Примечание: фактический код будет байтовым кодом. Ниже просто объясняется, что делает стирание типа.]

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());

    }


}

Первое, что нужно отметить, это то, что все будет работать гладко, и ClassCastException не будет выброшено, поскольку JVM легко может привести тип ex к Throwable.

Второе, на что следует обратить внимание, это то, что компилятор всегда заставлял нас перехватывать или передавать полученное проверенное исключение. JVM не делает таких проверок. Здесь, после приведения типа, в идеале SneakyThrow.sneakyThrowInner(ex); должен быть вынужден обрабатывать исключение Throwable, но помните, что байт-код этой версии доходит до JVM. Значит, мы как-то обманули компилятор.

Делай так:

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
        }
    }


}

Вывод: выполнено успешно