Блог

Я читал, что создание исключений — дорогостоящая операция. Однако разве создание собственных исключений не делает ваш код более выразительным и читаемым?

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

Меня интересуют другие мнения. Ценю любые предложения.

Не выбрасывать System.Exception . Никогда.

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

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

Обычно лучше всего использовать одно из заранее определенных исключений, если таковые имеются ( ArgumentException , InvalidOperationException и т.д.). Если ни одно из них не описывает ситуацию правильно, то пользовательский класс исключений — отличный вариант.

Накладные расходы на выдачу самого исключения (создание объекта, перемещение по стеку и т.д.) Являются дорогостоящими. Создание собственного класса exception практически не добавляет накладных расходов, поэтому, если вы собираетесь создавать исключение, не создавайте его new Exception("message") !

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

Накладные расходы на пользовательские исключения заключаются в том, что их еще нужно поддерживать и тестировать. Если существующее исключение подходит, используйте его вместо этого. (Например, ArgumentNullException вместо ZipCodeNullException .)

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

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

Вы никогда не должны бросать System.Exception , потому что тогда единственный способ перехватить is — это by catch(System.Exception) . Перехватывать такое общее исключение — очень плохая практика. Вы должны перехватывать конкретные исключения, которые дают вам возможность правильно обрабатывать их без сбоев программного обеспечения. Создавая пользовательские исключения, вы даете себе возможность потенциально распознавать их и восстанавливаться после них.

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

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

«Дорогой» — термин относительный, и, как уже следует из названия, исключение должно быть исключением, поэтому оно, вероятно, не повлияет на производительность вашего кода. Стоимость создания исключения, насколько я знаю, не зависит от типа исключения, поэтому вам не следует ограничивать себя системой.Исключение.

Но самое важное:http://c2.com/cgi/wiki ?Преждевременная оптимизация

Я предпочитаю использовать наиболее подходящее встроенное исключение, и если оно еще не существует, извлекаю свое собственное из System.Исключение ApplicationException.

Я бы не рекомендовал использовать System.Исключение с пользовательским сообщением.

Ваш коллега несет чушь. Создание исключения обходится одинаково независимо от класса.

И, честно говоря, все эти разговоры о «дорогих» исключениях — да, они дороже, чем проверка на нуль или что-то подобное, поэтому никогда не используйте их в качестве замены какой-либо проверки работоспособности, но их следует поощрять там, где они имеют смысл (например, IOException, это отличный вариант использования для них — проблемы с вводом-выводом являются исключительным случаем, и они обычно должны обрабатываться вне обычного потока программы).