Почему Exception.fillInStackTrace возвращает Throwable?

Я несколько озадачен вашим вопросом. В java-исключениях / обработке исключений явно есть что-то, чего вы не понимаете. Итак, начнем с самого начала.

В java все исключения (в том смысле, в котором этот термин используется в спецификации языка Java) являются экземплярами некоторого класса, который является подклассом java.lang.Throwable . Есть два (и только два) прямых подкласса Throwable; то есть java.lang.Exception и java.lang.Error . Экземпляры всех этих классов ... включая экземпляры Throwable и Error ... называются исключениями в JLS.

Обработчик исключений перехватывает исключения (в смысле JLS), присваивания которых совместимы с типом исключения, используемым в объявлении catch . Так, например:

try {
    ....
} catch (Exception ex) {
    ...
}

перехватит любое исключение, созданное в блоке try , которое является экземпляром java.lang.Exception или прямого или косвенного подтипа java .lang.Exception . Но он не будет ловить экземпляр java.lang.Throwable , потому что это (очевидно) не один из вышеперечисленных.

С другой стороны:

try {
    ....
} catch (Throwable ex) {
    ...
}

перехватит экземпляр java.lang.Throwable .

Рассматривая ваш пример в свете этого, становится очевидно, почему метод f не захватывает экземпляр Throwable: он не соответствует типу исключения в предложении catch! Напротив, в методе g экземпляр Exception соответствует типу исключения в предложении catch и поэтому перехватывается.

Я не понимаю, что вы говорите о том, что нужно бросить Throwable in g . Во-первых, тот факт, что метод объявляет, что он выбрасывает Throwable , не означает , что ему действительно нужно его выбросить. Все, что он говорит, это то, что он может выбросить что-то, что можно назначить Throwable ... возможно, в какой-нибудь будущей версии метода g . Во-вторых, если бы вы добавили throw e; во внешний блок catch, он выбросил бы что-то, что можно назначить для Throwable.

Наконец, как правило, создание экземпляров Throwable, Exception, Error и RuntimeException - плохая идея. И нужно быть очень осторожным, когда и как вы их поймаете. Например:

try {
     // throws an IOException if file is missing
    InputStream is = new FileInputStream("someFile.txt");
    // do other stuff
} catch (Exception ex) {
    System.err.println("File not found");
    // WRONG!!!  We might have caught some completely unrelated exception;
    // e.g. a NullPointerException, StackOverflowError, 
}

EDIT - в ответ на комментарий OP:

Но то, что я выбрасываю с помощью throw e.fillInStackTrace (); должно быть Intance of Throwable, а не Exception!

Документ Javadoc конкретно говорит, что возвращаемый объект является объектом исключения, для которого вы вызываете метод. Назначение метода fillInStacktrace () - заполнить трассировку стека для существующего объекта. Если вам нужно другое исключение, вы должны использовать новое для его создания.

На самом деле, я имею в виду, что внешний обработчик исключений не должен перехватывать Throwable, сгенерированный методом throw e.fillInStackTrace ().

Я объяснил, почему это происходит - потому что Throwable на самом деле является исходным исключением. Есть ли в моем объяснении что-то, чего вы не понимаете, или вы просто говорите, что вам не нравится способ определения Java?

РЕДАКТИРОВАТЬ 2

И если внешний обработчик исключений может обработать исключение Throwable, почему мы должны указать, что метод g будет генерировать исключение Throwable

. Вы неправильно поняли, о чем я говорил ... а именно, если вы ДЕЙСТВИТЕЛЬНО выбросили исключение, то выбрасывает Throwable не будет избыточным. OTOH, я, наконец, понял вашу жалобу.

Я думаю, что суть вашей жалобы в том, что вы получите ошибку компиляции со следующим:

public void function() throws Exception {
    try {
        throw new Exception();
    } catch (Exception ex) {
        throw ex.fillInStackTrace();
        // according to the static type checker, the above throws a Throwable
        // which has to be caught, or declared as thrown.  But we "know" that the 
        // exception cannot be anything other than an Exception.
    }
}

Я вижу, что это несколько неожиданно. Но, боюсь, это неизбежно. НЕТ способа (кроме серьезных изменений в системе типов Java) объявить сигнатуру fillInStacktrace , которая будет работать во всех случаях. Например, если вы переместите объявление метода в класс Exception, вы просто повторите ту же проблему с подтипами Exception. Но если вы попытаетесь выразить подпись с помощью параметра универсального типа, это повлечет за собой создание всех подклассов Throwable явных универсальных типов.

К счастью, лекарство действительно простое; приведите результат fillInStacktrace () следующим образом:

public void function() throws Exception {
    try {
        throw new Exception();
    } catch (Exception ex) {
        throw (Exception) (ex.fillInStackTrace());
    }
}

И наконец, очень необычно для приложения явно вызывать fillInStacktrace () . В свете этого разработчикам Java просто не стоило «напрягать кишки», пытаясь решить эту проблему. Тем более, что это действительно мелкие неудобства ... самое большее.

fillInStackTrace возвращает ссылку на тот же объект. Это метод chaining, позволяющий перебрасывать Exception и сбрасывать трассу стека исключения.

public static void m() {
    throw new RuntimeException();

}

public static void main(String[] args) throws Throwable {
    try {
        m();
    } catch (Exception e) {
        e.printStackTrace();
        throw e.fillInStackTrace();
    }
}

Типом возврата метода может быть только базовый тип, который является Throwable. Он может быть сгенерирован таким образом, что метод возвращает параметризованный тип. Но пока это не так.

RuntimeException e = new RuntimeException();
Throwable e1 = e.fillInStackTrace();
System.out.println(e1.getClass().getName()); //prints java.lang.RuntimeException
System.out.println(e == e1); //prints true

fillInStackTrace() определяется Throwable, а не Exception.

Не все подклассы Throwable являются исключениями (Error, например). Что касается Throwable, единственное, что может гарантировать возвращаемое значение fillInStackTrace() - это экземпляр Throwable (так как он просто возвращает тот же самый объект, как отметила Чандра Патни).

На самом деле FillInstacktrace возвращает тот же объект, на котором он был вызван.

E.FILLINSTACTTRACE == E всегда правда

Это всего лишь ярлык , вы также можете просто написать

    } catch (Exception e) {
        System.out.println("inner exception handler");
        e.fillInStackTrace();
        throw e;
    }

или использовать CAST

    throw (Exception) e.fillInStackTrace();

, то же самое происходит С initcouse () .

Я думаю, вы должны спросить Фрэнка Йеллина ( @author из java.lang.Exception). Как говорили другие, fillInStackTrace() объявлен в Throwable и документирован для возврата this, поэтому его тип возврата должен быть Throwable. Он просто унаследован по исключению . Фрэнк мог переопределить его в Исключении , вот так:

public class Exception extends Throwable{
    /**Narrows the type of the overridden method*/
    @Override
    public synchronized Exception fillInStackTrace() {
        super.fillInStackTrace();
        return this;
    }
}

... но он не переопределил. До появления Java 1.5, причина в том, что это привело бы к ошибке компиляции. В 1.5 и далее ковариативные типы возврата разрешены , и вышеизложенное является законным.

Но я думаю, что если бы описанное выше переопределение существовало, то вы бы спросили, почему RuntimeException не имеет подобного переопределения, почему ArrayStoreException не переопределяет это переопределение, и так далее. Так что Фрэнк и его друзья, наверное, просто не захотели писать эти сотни одинаковых переопределений.

Стоит отметить, что если вы имеете дело со своими собственными классами исключений, вы можете легко переопределить метод fillinStackTrace(), как я делал это выше, и получить более узкий тип, который вам нужен.

Используя дженерики, можно представить себе расширение объявления Throwable до:

public class Throwable<T extends Throwable<T>>{
    public synchronized native T fillInStackTrace();
}

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