Чи слід отримувати власні винятки з 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.