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