Почему это - “плохая идея” для выдачи собственных исключений?

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

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

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

Я думаю, что вам может потребоваться renderInContext , а не drawInContext . drawInContext - это более метод, который можно переопределить...

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

Я полагаю, что вам придется изменить модуль, чтобы использовать модуль IPV6 net. По умолчанию этот параметр не включен: http://eintr.blogspot.com/2009/03/bad-state-of-ipv6-in-perl.html . Я не верю, что есть что-то такое простое, как «preference-ipv6»

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

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

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

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

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

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

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

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

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

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

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

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

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

Из рекомендаций по проектированию .Net :

Рассмотрите возможность создания существующих исключений , находящихся в пространствах имен System , вместо создания пользовательских типов исключений .

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

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

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

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

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

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

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