2014-06-13 4 views
2

Я знаю правила об отмеченных исключениях, но я не могу полностью решить эту проблему. Почему второй метод не компилируется, но первый делает? Ошибка - это «Необработанное исключение типа Exception» в последнем типе. Я могу понять, почему я получаю эту ошибку, но я не понимаю, почему первый метод в порядке, у него должна быть такая же проблема ?!Java 7 Проверенные правила исключений

Как eclipse, так и intellij показывают ту же ошибку.

import java.util.concurrent.Callable; 

public class ThrowableWeirdness { 

    public void doWithMetrics(String name, Runnable runnable) { 

     try { 
      runnable.run(); 
     } catch (Throwable e) { 
      System.out.printf(name + ".failed"); 
      throw e; 
     } 
    } 

    public <RET> RET doWithMetrics(String name, Callable<RET> runnable) { 

     try { 
      return runnable.call(); 
     } catch (Throwable e) { 
      System.out.printf(name + ".failed"); 
      throw e; // Compilation error on this line: unhandled exception 
     } 
    } 
} 

Не могли бы вы объяснить разницу между этими двумя методами?

+0

Первый метод не скомпилирован ни на моем Eclipse ... Вы уверены, что не забыли некоторые «throws Throwable» в ваших подписях методов? – sp00m

+0

yep, такой же здесь, оба метода выдают неполученную ошибку исключения. –

+0

Странно. Я использую java 7, возможно, это имеет значение. Первый метод определяет компиляции, а также работает! –

ответ

5
  • В первом случае, runnable.run не бросать любого проверяемого Exception, так что ваши try/catch и Rethrow не выводится, чтобы бросить что-нибудь проверил, следовательно, он собирает
  • В вашем втором случае runnable.call() бросает Exception и обрабатывается, но затем возвращается.

Для того, чтобы исправить компиляции в этом случае, вы должны добавить throws заявление в вашем объявлении метода.

+0

Спасибо, это имеет смысл. Это просто, что в java 6 ни один метод не будет компилироваться, но в java 7 есть исправление для переустановки исключений. Я думаю, что я перейду к функции guava вместо Callable. –

+0

@DavidRoussel yes, rethrowing behavior отличается от 6 до 7. Я не знаком с Guava, но мне было бы немного странно требовать использования внешней структуры только для того, чтобы изменить поведение изменения ... – Mena

+0

Фактически в конце Я определил новый интерфейс для своей цели. Я хотел что-то вроде вызываемого, но без проверенного исключения. Я не фанат исключенных исключений. –

2

От Java 7 Onward, компилятор проверить блок попытаться проверить what exception are actually going to be raised:

Однако в Java SE 7, вы можете указать типы исключений FirstException и SecondException в бросках положение в rethrowException объявление метода. Компилятор Java SE 7 может определить, что исключение, выведенное оператором throw e, должно иметь , исходящее из блока try, и единственными исключениями, которые были выбраны блоком try , может быть FirstException и SecondException. Даже если параметр исключение из пункта улова, е, является тип исключения, компилятор может определить, что он является экземпляром либо FirstException или SecondException

если установить уровень источника до 1,6, оба из них не будет компилироваться.