День двести шестьдесят девятый. #BestPractices
Разработка Исключений
Выброс Исключений
Ошибка выполнения возникает всякий раз, когда член класса не может сделать то, для чего он был предназначен. Например, если метод
❌ ИЗБЕГАЙТЕ возвращения кодов ошибок из методов.
✅ ИСПОЛЬЗУЙТЕ исключения для сообщения об ошибках выполнения. Исключения являются основным средством сообщения об ошибках в фреймворках.
⚠️ РАССМОТРИТЕ вариант завершение процесса, вызвав
❌ ИЗБЕГАЙТЕ использования исключений для контроля нормального потока выполнения.
За исключением сбоев системы и операций, в которых возможно возникновение состояния гонки, разработчики фреймворков должны создавать такой API, чтобы пользователи могли писать код, который не генерирует исключения. Например, вы можете предоставить способ проверки предварительных условий перед вызовом метода. Метод, используемый для проверки предварительных условий другого метода, часто называют тестером, а метод, фактически выполняющий работу, называют исполнителем.
⚠️ РАССМОТРИТЕ последствия для производительности при использовании исключений. Частый выброс исключений может заметно повлиять на производительность большинства приложений.
❗️ НЕОБХОДИМО задокументировать все исключения, которые могут выбрасывать открытые члены вследствие нарушения контракта кода (а не из-за сбоя системы), и рассматривать их как часть контракта. Исключения, являющиеся частью контракта, не должны изменяться от одной версии к другой (то есть не должен изменяться тип исключения, и не должны добавляться новые исключения).
❌ ИЗБЕГАЙТЕ создания открытых членов, выбрасывающих или не выбрасывающих исключение в зависимости от какой-либо настройки.
❌ ИЗБЕГАЙТЕ открытых членов, возвращающих исключение, либо задающих исключение out параметру. Возврат исключений из общедоступных API вместо их выбрасывания сводит на нет многие преимущества системы обработки исключений.
⚠️ РАССМОТРИТЕ использование методов-конструкторов исключений. Обычно из разных мест кода выбрасывается одно и то же исключение. Чтобы избежать раздувания кода, используйте вспомогательные методы, которые создают исключение и инициализируют его свойства. Кроме того, члены, которые генерируют исключения, не встраиваются компилятором. Перемещение оператора throw внутрь вспомогательного метода может позволить встроить исходный член.
❌ ИЗБЕГАЙТЕ выбрасывания исключений из блоков фильтрации исключений. Когда фильтр исключений выбрасывает новое исключение, оно перехватывается CLR, а фильтр возвращает
❌ ИЗБЕГАЙТЕ явного выброса исключения из блоков
Источник: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/
Разработка Исключений
Выброс Исключений
Ошибка выполнения возникает всякий раз, когда член класса не может сделать то, для чего он был предназначен. Например, если метод
OpenFile не может вернуть дескриптор открытого файла вызывающей стороне, это будет считаться ошибкой выполнения. Большинству разработчиков удобно использовать исключения для ошибок использования, таких как деление на ноль или нулевые ссылки. В .Net Framework исключения используются для всех ошибок, включая ошибки выполнения.❌ ИЗБЕГАЙТЕ возвращения кодов ошибок из методов.
✅ ИСПОЛЬЗУЙТЕ исключения для сообщения об ошибках выполнения. Исключения являются основным средством сообщения об ошибках в фреймворках.
⚠️ РАССМОТРИТЕ вариант завершение процесса, вызвав
System.Environment.FailFast вместо выброса исключения, если ваш код сталкивается с ситуацией, когда он небезопасен для дальнейшего выполнения.❌ ИЗБЕГАЙТЕ использования исключений для контроля нормального потока выполнения.
За исключением сбоев системы и операций, в которых возможно возникновение состояния гонки, разработчики фреймворков должны создавать такой API, чтобы пользователи могли писать код, который не генерирует исключения. Например, вы можете предоставить способ проверки предварительных условий перед вызовом метода. Метод, используемый для проверки предварительных условий другого метода, часто называют тестером, а метод, фактически выполняющий работу, называют исполнителем.
⚠️ РАССМОТРИТЕ последствия для производительности при использовании исключений. Частый выброс исключений может заметно повлиять на производительность большинства приложений.
❗️ НЕОБХОДИМО задокументировать все исключения, которые могут выбрасывать открытые члены вследствие нарушения контракта кода (а не из-за сбоя системы), и рассматривать их как часть контракта. Исключения, являющиеся частью контракта, не должны изменяться от одной версии к другой (то есть не должен изменяться тип исключения, и не должны добавляться новые исключения).
❌ ИЗБЕГАЙТЕ создания открытых членов, выбрасывающих или не выбрасывающих исключение в зависимости от какой-либо настройки.
❌ ИЗБЕГАЙТЕ открытых членов, возвращающих исключение, либо задающих исключение out параметру. Возврат исключений из общедоступных API вместо их выбрасывания сводит на нет многие преимущества системы обработки исключений.
⚠️ РАССМОТРИТЕ использование методов-конструкторов исключений. Обычно из разных мест кода выбрасывается одно и то же исключение. Чтобы избежать раздувания кода, используйте вспомогательные методы, которые создают исключение и инициализируют его свойства. Кроме того, члены, которые генерируют исключения, не встраиваются компилятором. Перемещение оператора throw внутрь вспомогательного метода может позволить встроить исходный член.
❌ ИЗБЕГАЙТЕ выбрасывания исключений из блоков фильтрации исключений. Когда фильтр исключений выбрасывает новое исключение, оно перехватывается CLR, а фильтр возвращает
false. Это поведение неотличимо от фильтра, который успешно выполняется и возвращает false, поэтому такое исключение очень трудно отладить.❌ ИЗБЕГАЙТЕ явного выброса исключения из блоков
finally. Но из блока finally допустимо вызывать методы, которые могут выбрасывать исключения.Источник: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/