Стоимость пользовательских исключений

Question

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

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

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

Answer 1

Не бросайте System.Exception. Когда-либо.

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

Но самое важное: http://c2.com/cgi/wiki?PrematureOptimization

Answer 7

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

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

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

Answer 8

Ваш коллега говорит глупости.Бросок исключения - это одна и та же стоимость независимо от класса.

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