Зачем создавать пользовательские исключения?

Question

Зачем нам создавать пользовательские исключения в .NET?

Answer 1

Конкретных таможенных исключения позволяют разделять различные типы ошибок для утверждений об улове.Общая конструкция для обработки исключений заключается в следующем:

try 
{} 
catch (Exception ex) 
{} 

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

try 
{} 
catch (CustomException1 ex1) 
{ 
    //handle CustomException1 type errors here 
} 
catch (CustomException2 ex2) 
{ 
    //handle CustomException2 type errors here 
} 
catch (Exception ex) 
{ 
    //handle all other types of exceptions here 
} 

Ergo, конкретные исключения позволяют уровень мельче контроля над вашей обработкой исключений. Это преимущество распространяется не только на пользовательские исключения, но и на все другие типы исключений в системных библиотеках .NET.

Answer 2

Я не уверен, почему «технически», но позволяет сказать, что у меня есть приложение/веб-сайт, который использует разрешения. Если кто-то не имеет правильного разрешения, его глупость бросить исключение DivideByZero или исключение IOException. Вместо этого я могу создать мое AccessDeniedException, которое поможет мне отлаживать позже.

Answer 3

Так что вы также можете бросить их самостоятельно, а затем поймать их и узнать точно что они означают.

Также: если вы создаете библиотеку классов/framework/api, часто бывает полезно создать исключение BaseException, из-за которого наследуются другие исключения в коде. Затем, когда ваш код вызывает исключения, программисты, которые его используют, могут быстро узнать источник исключения.

Answer 4

Потому что это может сделать ваши намерения понятными, и вы также можете отслеживать использование с использованием функциональных возможностей IDE. Скажем, что у вас есть пользовательская бэкэнд-система под названием «FooBar», и вы создаете «FooBarDownException», вы можете отслеживать использование этого исключения, чтобы идентифицировать любую пользовательскую логику, содержащую ваше приложение, потому что FooBar не работает. Вы можете выбрать этот особый тип исключения и игнорировать другие, избегая перегрузок и условной логики в обработчиках исключений. Это действительно просто еще одна версия сильной печати. Это также означает, что вы можете избежать комментариев в своем коде, потому что у исключения есть намерение, раскрывающее имя.

Answer 5

По той же причине вы бы создали разные коды выхода для приложения не.NET: для указания различных ошибок, специфичных для приложения. Как ... ConnectionBrokenException или um ... UserSmellsBadException ... или что-то в этом роде.

Таким образом, вы можете точно знать, что пошло не так, и действовать надлежащим образом. Например, если вы попытаетесь отправить некоторые данные, а класс переноса данных выдает ConnectionBrokenException, вы можете открыть диалоговое окно повторного подключения и попытаться снова подключиться. Затем метод повторного подключения будет вызывать ConnectionTimeoutException, если он истечет, и вы можете снова действовать соответствующим образом.

Answer 6

Стандартные исключения .NET не покрывают все плохое, что может пойти не так в любом приложении и не предназначено. Если ваша программа не очень проста, вероятно, вам придется создать хотя бы несколько пользовательских исключений.

Answer 7

Как писал Джоэл: «Вы также можете бросить их сами, а затем поймать их и точно знать, что они означают.

Кроме того, вы можете добавить конкретную информацию о проблеме, чтобы позволить обработчику исключений действовать более точно.

Answer 8

Я сделал длинный пост в блоге на эту тему в последнее время:

http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx

Суть его сводится к тому: создать специальное исключение только если один из следующих условий

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

Answer 9

С одной стороны, Исключения реализованы в Библиотеке, а не на языке - как они могут создавать исключения в библиотеке? Я уверен, что вы не отстаиваете, что системные библиотеки должны иметь другой набор правил.

С другой стороны, на самом деле можно использовать дерево объектов исключений. Унаследованные исключения могут иметь специальные атрибуты, если хотите - их можно использовать для более сложных вещей, чем они есть. Я не сторонник их использования в качестве механизма передачи данных общего характера или чего-то еще (хотя они могут быть), но я мог видеть случай, когда кто-то реализовал специальное решение для регистрации, которое требовало специального атрибута в Exception ...

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

В любом случае, я не сторонник этого, я просто говорю, что это возможно. Первый абзац - это реальный ответ.

Answer 10

Вы не должны, если встроенные исключения надлежащим образом описывают проблему/исключение. Я бы не стал создавать собственные базовые классы для создания пользовательских ArgumentException, ArgumentNullException или InvalidOperationException.

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

Если вы выбрали и поймаете исключение самостоятельно, может возникнуть необходимость в специальном исключении.

Answer 11

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

Я писал об этом особом случае:

http://blog.mikecouturier.com/2010/01/creating-custom-exceptions-in-net-right.html