Почему «плохая идея» бросать свои собственные исключения? - PullRequest
8 голосов
/ 07 февраля 2010

Почему «плохая идея» - создавать свои собственные исключения?

найдено здесь

Ответы [ 10 ]

24 голосов
/ 07 февраля 2010

В общем, вполне нормально бросать свои собственные исключения. Возможно, вы хотели спросить: «Когда не стоит бросать мое собственное исключение?»

Один случай, когда вы должны выдавать стандартное исключение. Например, если ваш метод принимает имя файла и должен возвращать файл, вы, вероятно, должны выбросить стандартное FileNotFoundException вашей платформы, а не PeanutPowersFileNotFoundException. Если вы действительно хотите выбросить собственное исключение, вам, вероятно, следует расширить стандартное исключение FileNotFoundException.

Обновление: Блох объясняет это в пункте 60 из Effective Java

4 голосов
/ 07 февраля 2010

Это не так. Вы должны создавать и генерировать пользовательские исключения всякий раз, когда у вас есть исключительная ситуация.

3 голосов
/ 07 февраля 2010

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

Из .Net руководящих принципов проектирования :

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

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

Не создавать и не создавать новые исключения просто чтобы исключение вашей команды.

3 голосов
/ 07 февраля 2010

Не предусмотрено, что они являются производными от стандартного базового типа исключения (std :: exception в c ++ или Exception в python и т. Д ...)

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

2 голосов
/ 07 февраля 2010

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

2 голосов
/ 07 февраля 2010

Нет ничего плохого в создании ваших собственных исключений, которые могут быть адаптированы для передачи именно той информации, которая подходит для вашей ситуации. ConfigFileNotFoundException передает больше информации, чем FileNotFoundException (какой файл мы не нашли?).

Но, безусловно, убедитесь, что вы перехватываете и обрабатываете все без исключения внутри из вашего кода. Когда исключение вылетает в какое-то место за пределами вашего модуля (назовите его package, назовите его пространством имен), эти люди даже не узнают, что оно существует, тем более, что с ним делать. За исключением catch (Throwable t) {/* whut? */}.

2 голосов
/ 07 февраля 2010

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

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

Использование генерации исключений для управления бизнес-логикой в ​​дополнение к плохому шаблону проектирования также влияет на производительность - создание и отлов исключений довольно дорогой по сравнению с ветвлением на основе результатов, возвращаемых методом

2 голосов
/ 07 февраля 2010

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

Если вы хотите сообщить пользователю вашего API, что он предоставил недопустимый аргумент, вы должны выдать ArgumentException, но если ваша библиотека выходит из строя по какой-то конкретной причине библиотеки, которую вы не можете передать в обычном исключении, Вы должны свернуть свое собственное и позволить ему содержать информацию, необходимую разработчику.

2 голосов
/ 07 февраля 2010

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

Под "перебрасыванием" я имею в виду перехват исключения, а затем создание нового и его выброс. Это может быть проблематично, так как вы можете в конечном итоге использовать исходную трассировку стека и потерять весь контекст ошибки.

1 голос
/ 07 февраля 2010

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...