Расширение Throwable в Java

Является ли этот метод (ab) с использованием исключения допустимым? (Есть ли для него название?)

На мой взгляд, это не очень хорошая идея:

• Это нарушает принцип наименьшего удивления , это затрудняет чтение кода, особенно если в этом нет ничего исключительного.
• Бросать исключение является очень дорогой операцией в Java (хотя это может и не быть проблемой).

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

См. Также:

• Бросать исключения для управления запахом потока кода?

Если допустимо, следует FlyingPig расширяет Throwable, или Exception просто отлично? (хотя в его обстоятельствах нет ничего исключительного?)

Могут быть ситуации, когда вы хотите поймать Throwable, чтобы не только поймать Exception , но и Error но это редко, люди обычно не ловят Throwable. Но мне не удается найти ситуацию, в которой вы хотели бы выбросить подкласс Throwable.

И я также думаю, что расширение Throwable не делает вещи выглядящими менее «исключительными» , они заставляют его выглядеть хуже - что полностью противоречит намерению.

Итак, в заключение, если вы действительно хотите что-то бросить, бросьте подкласс Exception.

См. Также:

• Когда следует использовать Throwable вместо нового исключения?

По мере того, как этот вопрос развивался, я вижу, что неправильно понял смысл первоначального вопроса, поэтому некоторые другие ответы, вероятно, более актуальны. Я оставлю этот ответ здесь, так как он все еще может быть полезен для других, у которых есть подобный вопрос, и найти эту страницу во время поиска ответа на свой вопрос.

Нет ничего плохого в расширении Throwable, чтобы иметь возможность генерировать (и обрабатывать) пользовательские исключения. Тем не менее, вы должны помнить следующее:

• Использование наиболее конкретного возможного исключения - отличная идея. Это позволит вызывающей стороне по-разному обрабатывать различные типы исключений. Важно помнить об иерархии классов исключения, поэтому пользовательское исключение должно расширять другой тип Throwable, максимально приближенный к вашему исключению.
• Расширение Throwable может быть слишком высокого уровня. Попробуйте вместо этого расширить Exception или RuntimeException (или исключение более низкого уровня, которое ближе к причине, по которой вы генерируете исключение). Имейте в виду разницу между RuntimeException и Exception.
• Вызов метода, который генерирует Exception (или подкласс Exception), должен быть заключен в блок try / catch, который способен обрабатывать исключение. Это хорошо для случаев, когда вы ожидаете, что что-то пойдет не так, из-за обстоятельств, которые могут быть вне вашего контроля (например, из-за сбоя сети).
• Вызов метода, который генерирует RuntimeException (или его подкласс), не нужно заключать в блок try / catch, который может обработать исключение. (Это, конечно, может быть, но это не обязательно.) Это больше для исключений, которые действительно не следует ожидать.

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

public class Pig extends Throwable { ... }
public class FlyingPig extends Pig { ... }
public class Swine extends Pig { ... }
public class CustomRuntimeException extends RuntimeException { ... }

И некоторые методы

public void foo() throws Pig { ... }
public void bar() throws FlyingPig, Swine { ... }
// suppose this next method could throw a CustomRuntimeException, but it
// doesn't need to be declared, since CustomRuntimeException is a subclass
// of RuntimeException
public void baz() { ... } 

Теперь у вас может быть некоторый код, который вызывает эти методы похожи на это:

try {
    foo();
} catch (Pig e) {
    ...
}

try {
    bar();
} catch (Pig e) {
    ...
}

baz();

Обратите внимание, что когда мы вызываем bar(), мы можем просто поймать Pig, так как FlyingPig и Swine расширяются Pig. Это полезно, если вы хотите сделать то же самое для обработки любого исключения. Вы могли бы, однако, обращаться с ними по-другому:

try {
    bar();
} catch (FlyingPig e) {
    ...
} catch (Swine e) {
    ...
}

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

Самая большая проблема, о которой я могу думать, - это прагматический мир, иногда есть веские причины для перехвата java.lang.Exception. Ваш новый тип throwable будет пролетать мимо блоков try-catch, которые имели все разумные ожидания подавления (или регистрации, упаковки и т.д.) всех возможных нефатальных проблем.

С другой стороны, если вы проводите обслуживание старой системы, которая un оправданно подавляет java.lang.Exception, вы можете обмануть ее. (Предполагая, что искренний призыв потратить время на то, чтобы исправить это должным образом, отклоняется).

Аннотация org.junit.Test включает класс None , который расширяет Throwable и используется в качестве значения по умолчанию для ожидаемого ] параметр аннотации.

Играй! framework использует что-то подобное для обработки запросов. Обработка запроса проходит через множество уровней (маршрутизация, промежуточное ПО, контроллеры, рендеринг шаблонов), и на последнем уровне визуализированный HTML обертывается в бросок и выбрасывается, который самый верхний уровень перехватывает, разворачивает и отправляет в клиент. Таким образом, ни одному из методов во многих задействованных слоях не нужно явно возвращать объект ответа, а также им не нужно передавать объект ответа в качестве аргумента для распространения и изменения.

Я немного поверхностен в деталях. Вы можете просмотреть код Play! рамки для деталей.

Вот запись в блоге Джона Роуза, архитектора HotSpot:

http://blogs.oracle.com/jrose/entry/longjumps_considered_inexpensive

Речь идет о «злоупотреблении» исключениями для управления потоком. Немного другой вариант использования, но.. Короче говоря, это работает очень хорошо - если вы предварительно выделяете/клонируете свои исключения, чтобы предотвратить создание трассировки стека.

Я думаю, что этот метод оправдан, если он «спрятан» от клиентов. IE, ваш FlyingPig никогда не сможет покинуть вашу библиотеку (все общедоступные методы должны транзитивно гарантировать, что он не будет выброшен). Один из способов гарантировать это — сделать его проверенным исключением.

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