Які типи винятків слід викинути за недійсні або несподівані параметри в .NET? Коли я б обрав один замість іншого?
Який виняток ви б використали, якщо функція очікувала ціле число, що відповідає місяцю, і ви перейшли у "42"? Чи потрапить це в категорію "поза діапазоном", хоча це не колекція?
Відповіді:
Я хотів би використовувати: ArgumentException, ArgumentNullException, і ArgumentOutOfRangeException.
ArgumentException - Щось не так з аргументом.ArgumentNullException - Аргумент недійсний.ArgumentOutOfRangeException - Я не дуже використовую цей, але звичайне використання - це індексація до колекції та надання індексу, який є великим.Є й інші варіанти, які не так зосереджуються на самому аргументі, а скоріше оцінюють виклик у цілому:
InvalidOperationException- Аргумент може бути в порядку, але не в поточному стані об'єкта. Кредит йде на STW (раніше Yoooder). Проголосуйте також за його відповідь .NotSupportedException- Передані аргументи є дійсними, але просто не підтримуються в цій реалізації. Уявіть собі FTP-клієнта, і ви передаєте команду, у якій клієнт не підтримує.Хитрість полягає в тому, щоб кинути виняток, який найкраще виражає, чому метод не можна назвати таким, яким він є. В ідеалі виняток має бути детально про те, що пішло не так, чому це неправильно та як це виправити.
Мені подобається, коли повідомлення про помилки вказують на допомогу, документацію чи інші ресурси. Наприклад, Microsoft зробила перший крок зі своїми статтями про КБ, наприклад, "Чому я отримую повідомлення про помилку" Операція перервана ", коли я відвідую веб-сторінку в Internet Explorer?" . Коли ви зіткнулися з помилкою, вони вказують на статтю KB у повідомленні про помилку. Те, що вони не роблять добре, це те, що вони не скажуть вам, чому конкретно це не вдалося.
Завдяки STW (колишній Yoooder) знову за коментарі.
У відповідь на ваш наступний результат я б кинув ArgumentOutOfRangeException. Подивіться, що MSDN говорить про цей виняток:
ArgumentOutOfRangeExceptionвикидається, коли викликається метод, і принаймні один з аргументів, переданих методу, не має нульової посилання (Nothingу Visual Basic) і не містить дійсного значення.
Отже, у цьому випадку ви передаєте значення, але це не є дійсним значенням, оскільки ваш діапазон становить 1–12. Однак, як ви документуєте, це дає зрозуміти, що кидає ваш API. Тому що, хоча я можу сказати ArgumentOutOfRangeException, інший розробник може сказати ArgumentException. Зробіть це легко і задокументуйте поведінку.
FormatException: Виняток, який видається, коли формат аргументу недійсний або коли складений рядок формату недостатньо сформований.
Я проголосував за відповідь Джоша , але хотів би додати ще один до списку:
System.InvalidOperationException слід кинути, якщо аргумент дійсний, але об'єкт знаходиться в стані, коли аргумент не слід використовувати.
Оновлення, взяті з MSDN:
InvalidOperationException застосовується у випадках, коли недосвідчення методу викликано причинами, відмінними від недійсних аргументів.
Скажімо, що ваш об’єкт має метод PerformAction (enmSomeAction action), дійсними enmSomeActions є Open and Close. Якщо ви викликаєте PerformAction (enmSomeAction.Open) двічі поспіль, то другий виклик повинен кинути InvalidOperationException (оскільки аругмент був дійсним, але не для поточного стану елемента управління)
Оскільки ви вже робите правильно, захищаючи програмування, у мене є ще одне виключення - ObjectDisposedException. Якщо ваш об'єкт реалізує IDisposable, у вас завжди повинна бути змінна класу, яка відстежує розміщений стан; якщо ваш об’єкт був розміщений і на нього викликається метод, ви повинні підняти ObjectDisposedException:
public void SomeMethod()
{
If (m_Disposed) {
throw new ObjectDisposedException("Object has been disposed")
}
// ... Normal execution code
}Оновлення: щоб відповісти на ваше подальше спостереження: це дещо неоднозначна ситуація, яка ускладнюється загальним (не в сенсі .NET Generics) типом даних, що використовуються для представлення конкретного набору даних; перерахунок або інший сильно набраний об'єкт був би більш ідеальним, але ми не завжди маємо такий контроль.
Я особисто схиляюся до ArgumentOutOfRangeException і надаю повідомлення, яке вказує, що дійсні значення - 1-12. Моє міркування полягає в тому, що якщо ви говорите про місяці, якщо вважати, що всі цілі подання місяців є дійсними, то ви очікуєте значення в діапазоні 1-12. Якби тільки певні місяці (як, наприклад, місяці, що мали 31 день) були дійсними, то ти б не мав справу з діапазоном per se, і я б кинув загальний ArgumentException, який вказав дійсні значення, і я також задокументував би їх у коментарях методу.
Залежно від фактичного значення та того, який виняток найбільше підходить:
ArgumentException (щось не в порядку зі значенням)
ArgumentNullException (аргумент є нульовим, поки це не дозволено)
ArgumentOutOfRangeException (аргумент має значення поза допустимим діапазоном)
Якщо це недостатньо точно, вийдіть із власного класу виключень ArgumentException.
Відповідь Yoooder мене просвітила. Вхід недійсний, якщо він недійсний у будь-який час, тоді як вхід несподіваний, якщо він недійсний для поточного стану системи. Тож у пізнішому випадку InvalidOperationExceptionвибір є розумним.
ArgumentException викидається, коли викликається метод, і принаймні один із переданих аргументів не відповідає специфікації параметра викликаного методу. Усі екземпляри ArgumentException повинні містити змістовне повідомлення про помилку, що описує недійсний аргумент, а також очікуваний діапазон значень аргументу.
Також існує кілька підкласів для конкретних типів інвалідності. Посилання містить підсумки підтипів і коли вони повинні застосовуватися.
Коротка відповідь:
Ні
Більш довга відповідь:
використання Argument * Виняток (за винятком бібліотеки, яка ввімкнений продукт, наприклад, бібліотека компонентів) - це запах. Винятки - це вирішення виняткової ситуації, а не помилки та недолік користувачів (тобто споживача API).
Найдовша відповідь:
Кидання винятків для невірних аргументів є грубим, якщо ви не пишете бібліотеку.
Я вважаю за краще використовувати твердження з двох (або більше) причин:
Ось як виглядає обробка нульового виключення (очевидно, саркастичний):
try {
library.Method(null);
}
catch (ArgumentNullException e) {
// retry with real argument this time
library.Method(realArgument);
}Винятки повинні використовуватися, коли ситуація очікується, але виняткова (трапляються речі, що не є під контролем споживача, наприклад, вихід з ладу). Аргумент * Виняток - це вказівка на помилку, і він (на мою думку) обробляється тестами та допомагає з Debug.Assert
BTW: У цьому конкретному випадку ви могли використовувати тип місяця замість int. C # не вистачає, коли справа стосується безпеки типу (Aspect # rulez!), Але іноді ви можете запобігти (або зловити під час компіляції) ці помилки разом.
І так, MicroSoft в цьому помиляється.
Існує стандартний ArgumentException, який ви можете використовувати, або ви можете підклас і зробити свій власний. Існує кілька специфічних класів ArgumentException:
http://msdn.microsoft.com/en-us/library/system.argumentexception(VS.71).aspx
Хто б не працював найкраще.