.NET Разработчик

День двести семидесятый. #BestPractices

Разработка Исключений

Использование Стандартных Типов Исключений

Далее описываются стандартные исключения, предоставляемые платформой, и подробности их использования. Список ни в коем случае не является исчерпывающим. Обратитесь к справочной документации по .NET Framework для использования других типов исключений.



Exception и SystemException

❌ ИЗБЕГАЙТЕ выбрасывания System.Exception или System.SystemException.

❌ ИЗБЕГАЙТЕ перехватывания System.Exception или System.SystemException во внутреннем коде, если только вы не собираетесь их повторно выбросить.

❌ ИЗБЕГАЙТЕ перехватывания System.Exception или System.SystemException, за исключением обработчиков исключений верхнего уровня.



ApplicationException

❌ ИЗБЕГАЙТЕ выбрасывания и наследования от ApplicationException.



InvalidOperationException

✅ ИСПОЛЬЗУЙТЕ InvalidOperationException, если объект находится в неподходящем состоянии.



ArgumentException, ArgumentNullException и ArgumentOutOfRangeException

✅ ИСПОЛЬЗУЙТЕ ArgumentException или один из его подтипов, если члену передаётся неверный аргумент. Отдавайте предпочтение наиболее производному типу исключения, если это возможно.

✅ ИСПОЛЬЗУЙТЕ свойство ParamName при создании одного из подклассов ArgumentException. Это свойство представляет имя параметра, вызвавшего исключение. Обратите внимание, что это свойство также может быть установлено с использованием одной из перегрузок конструктора.

✅ ИСПОЛЬЗУЙТЕ ключевое слово value для имени неявного параметра-значения в установщике свойства.



NullReferenceException, IndexOutOfRangeException и AccessViolationException

❌ ИЗБЕГАЙТЕ явного или неявного выбрасывания исключений типа NullReferenceException, AccessViolationException или IndexOutOfRangeException в публично вызываемом API. Эти типы исключения зарезервированы, выбрасываются механизмом выполнения и в большинстве случаев указывают на ошибку в коде. Выполняйте проверку аргументов, чтобы избежать выброса этих исключений. Выброс этих исключений раскрывает подробности реализации вашего метода, которая может меняться со временем.



StackOverflowException

❌ ИЗБЕГАЙТЕ явного выбрасывания StackOverflowException. Это исключение должно явно выбрасываться только CLR.

❌ ИЗБЕГАЙТЕ перехвата StackOverflowException. Практически невозможно написать согласованный управляемый код при наличии произвольных переполнений стека. Неуправляемые части CLR остаются согласованными благодаря использованию проверок для перемещения переполнений стека в четко определенные места, а не путем восстановлений после произвольных переполнений стека.



OutOfMemoryException

❌ ИЗБЕГАЙТЕ явного выбрасывания OutOfMemoryException. Это исключение должно выбрасываться только инфраструктурой CLR.



ComException, SEHException и ExecutionEngineException

❌ ИЗБЕГАЙТЕ явного выбрасывания COMException, ExecutionEngineException или SEHException. Эти исключения должны выбрасываться только инфраструктурой CLR.



Источник: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/