Чи слід отримувати власні винятки з Exception або ApplicationException у .NET?


74

Що є найкращою практикою при створенні класів винятків у .NET-рішенні: похідне від System.Exceptionабо з System.ApplicationException?

Відповіді:


63

Відповідно до Джеффрі Ріхтера в книзі Framework Guidelines:

System.ApplicationException це клас, який не повинен бути частиною .NET framework.

Він мав мати якесь значення в тому, що ви могли б потенційно вловити "всі" винятки додатків, але шаблон не був дотриманий, тому він не має значення.


3
Неймовірно, якщо врахувати матеріали Microsoft Press для іспиту MCTS 70-536, явно говорять про протилежне ... га!
Dave Lawrence

Ніколи не довіряйте повністю іспитам з питань MS. Я прочитав їх небагато - завжди повний помилок.
user1068352

Це насправді не відповідає на питання. Ви хочете сказати, що винятки спеціальних додатків повинні успадковуватися від Exception? Якщо так, чи можете ви так сказати?
Патрік Салапський,

28

Ви повинні отримувати власні винятки з System.Exception.

Навіть MSDN зараз каже ігнорувати ApplicationException:

Якщо ви розробляєте програму, яка повинна створити власні винятки, вам рекомендується отримати спеціальні винятки з класу винятків. Спочатку вважалося, що власні винятки повинні походити з класу ApplicationException; однак на практиці не встановлено, що це додає значної вартості. Для отримання додаткової інформації див. Найкращі практики щодо обробки винятків .

http://msdn.microsoft.com/en-us/library/system.applicationexception.aspx


1
Цитата це говорить, але добре, відредагована, щоб бути більш чіткою.
Blorgbeard вийшов

18

ApplicationExceptionвважається марним - це вагомий і критичний аргумент проти ApplicationException.

Підсумок: не використовуйте його. Вивести з Exception.


Так, у Конрада це правильно. На відповідну ноту: інша річ, яка вважається корисною (або "найкращою практикою"), але насправді не є реалізацією ICloneable .
Крейг

13

Самі автори фреймворку вважають ApplicationException марним:

https://web.archive.org/web/20190904221653/https://blogs.msdn.microsoft.com/kcwalina/2006/06/23/applicationexception-considered-useless/

з приємним продовженням тут:

https://web.archive.org/web/20190828075736/https://blogs.msdn.microsoft.com/kcwalina/2006/07/05/choose-the-right-type-of-exception-to-throw/

Якщо виникають сумніви, я дотримуюся їхньої книги “Framework Design Guidelines”.

http://www.amazon.com/Framework-Design-Guidelines-Conventions-Development/dp/0321246756

Там далі обговорюється тема повідомлення в блозі.

rp


1

Я звик робити:

private void buttonFoo_Click()
{
    try
    {
       foo();
    } 
    catch(ApplicationException ex)
    {
      Log.UserWarning(ex);
      MessageVox.Show(ex.Message);
    }
    catch(Exception ex)
    {
       Log.CodeError(ex);
       MessageBox.Show("Internal error.");
    }
}

Це дозволяє зробити різницю між:

  • Системна помилка коду C #, яку я повинен виправити.
  • "Звичайна" помилка користувача, яка не потребує від мене виправлення.

Я знаю, що не рекомендується використовувати ApplicationException, але це чудово працює, оскільки є дуже мало класів , які не поважають шаблон ApplicationException.


2
Дуже мало, про що ви знаєте. Будь-хто, хто дотримується вказівок щодо проектування фреймворків, не буде походити від ApplicationException. Якщо ви хочете зберегти цей шаблон, вам потрібно створити власний тип, такий як MyApplicationExcptionBase, і вивести з нього всі власні винятки. До речі, в Інструкціях сказано створити кілька похідних типів винятків.
Джон Сондерс,

Ви праві: сьогодні, якщо мені довелося починати з нуля, я створив виняток "UserError". Тим не менше, я не буду переробляти свій старий код: це не дуже критично.
Олів'є де Рівуар
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.