Создание исключений
Примечание.
Это содержимое перепечатывается разрешением Pearson Education, Inc. из руководства по проектированию платформы: соглашения, идиомы и шаблоны для повторно используемых библиотек .NET, 2-го выпуска. Этот выпуск был опубликован в 2008 году, и книга с тех пор была полностью пересмотрена в третьем выпуске. Некоторые сведения на этой странице могут быть устаревшими.
Чтобы использовать рекомендации по созданию исключений, описанных в этом разделе, необходимо хорошо понимать, что такое сбой при выполнении. Сбой при выполнении происходит каждый раз, когда элемент не может выполнить действие, для которого он был создан (что предполагает его имя). Например, если метод OpenFile не может вернуть открытый дескриптор файла вызывающему объекту, это будет считаться сбоем при выполнении.
Большинство разработчиков хорошо знакомы с использованием исключений для ошибок использования, таких как деление на ноль или пустая ссылка. На платформе исключения используются для всех условий ошибок, включая ошибки выполнения.
❌ НЕ возвращайте коды ошибок.
Исключения являются основным средством для ведения отчетов об ошибках на платформах.
✔️ НЕ сообщайте о сбоях при выполнении, создавая исключения.
✔️ РАССМОТРИТЕ возможность завершения процесса, вызвав System.Environment.FailFast (функция .NET Framework 2.0) вместо создания исключения, если возникает ситуация, когда дальнейшее выполнение кода небезопасно.
❌ НЕ используйте исключения для обычного потока управления, если это возможно.
За исключением системных сбоев и операций с потенциальными состояниями гонки, конструкторы платформы должны разрабатывать интерфейсы API так, чтобы пользователи могли писать код, который не создает исключения. Например, можно предоставить способ проверки предусловий перед вызовом элемента, чтобы пользователи могли написать код, который не создает исключения.
Элемент, используемый для проверки предусловий другого элемента, часто называется тестировщиком (tester), а элемент, который фактически выполняет работу, — исполнителем (doer).
Бывают случаи, когда шаблон Tester-Doer может иметь неприемлемо низкую производительность. В качестве альтернативы вы можете использовать шаблон Try-Parse (дополнительные сведения см. в статье Исключения и производительность).
✔️ ОЦЕНИТЕ влияние создания исключений на производительность. Создание свыше 100 исключений в секунду, скорее всего, заметно повлияет на производительность большинства приложений.
✔️ ЗАДОКУМЕНТИРУЙТЕ все исключения, созданные открыто вызываемыми элементами из-за нарушения контракта элемента (а не сбоя системы). Рассматривайте их как часть контракта.
Исключения, которые являются частью контракта, не должны изменяться при обновлении версии (т. е. не следует изменять тип исключения и добавлять новые исключения).
❌ НЕ используйте открытые элементы, которые могут создавать либо не создавать исключения, в зависимости от определенного условия.
❌ НЕ используйте открытые элементы, которые возвращают исключения в качестве возвращаемого значения или параметра out.
Если исключения не создаются, а возвращаются из открытых интерфейсов API, многие преимущества создания отчетов об ошибках на основе исключений будут потеряны.
✔️ Рассмотрите возможность использования методов построителя исключений.
Обычно создается одно и то же исключение из различных мест. Чтобы избежать раздувания кода, используйте вспомогательные методы, которые создают исключения и инициализируют их свойства.
Кроме того, элементы, которые создают исключения, не являются встроенными. Перемещение оператора throw в построитель может привести к встраиванию элемента.
❌ НЕ создавайте исключения из блоков фильтра исключений.
Если фильтр исключений вызывает исключение, то оно перехватывается средой CLR, а фильтр возвращает значение false. Это поведение неотличимо от применения фильтра и явным образом возвращает значение false, поэтому его очень сложно отлаживать.
❌ ИЗБЕГАЙТЕ явного создания исключений из блоков finally. Допускаются неявно созданные исключения в результате вызова методов.
Фрагменты: © Корпорация Майкрософт (Microsoft Corporation), 2005, 2009. Все права защищены.
Перепечатано с разрешения Pearson Education, Inc. из книги Инфраструктура программных проектов. Соглашения, идиомы и шаблоны для многократно используемых библиотек .NET (2-е издание), авторы: Кржиштоф Цвалина (Krzysztof Cwalina) и Брэд Абрамс (Brad Abrams). Книга опубликована 22 октября 2008 г. издательством Addison-Wesley Professional в рамках серии, посвященной разработке для Microsoft Windows.