Этот вопрос касается соглашения и интерпретации MSDN, поэтому я не думаю, что это основано прежде всего на мнениях.Должен ли я бросать исключение ArgumentException?
Мне интересно, ArgumentException: У меня есть класс строителя, который используется для создания объекта фильтра, который будет применяться при получении набора сообщений электронной почты из почтового ящика. У конструктора есть несколько способов для установки параметров фильтра. Например, у меня есть два метода для установки диапазона «дата отправки» фильтра, отправленного до XX и/или отправленного после XX. Я хочу добавить предложение охраны для каждого, которое будет генерировать исключение, если, например, предоставленная «до» дата равна после предоставленной «после» даты. Я хотел бы сделать это с помощью общего метода проверки:
/// <summary>
/// This class provides methods for validating dates in various ways.
/// </summary>
internal static class DateValidation
{
/// <summary>
/// Validate the provided "start" and "end" date/time values.
/// If they do not represent a valid range, throw an exception.
/// </summary>
/// <param name="start">The date/time that represents the start of the range.</param>
/// <param name="end">The date/time that represents the end of the range.</param>
internal static void ValidateDateTimeRange(DateTime? start, DateTime? end)
{
if (start.HasValue && end.HasValue)
{
if (start.Value > end.Value)
throw new Exception(
string.Format(@"The start date/time ""{0}"" " +
@"occurs after the end date/time ""{1}"".",
start.ToString(), end.ToString()));
}
}
}
Вот методы два строителя:
/// <summary>
/// Set a value which represents a date/time after which
/// messages must have been sent to be part of filtered output.
/// </summary>
/// <param name="afterDateTime">The date/time after which
/// messages must have been sent to be part of filtered output.</param>
public void SetSentAfterDateTime(DateTime afterDateTime)
{
DateValidation.ValidateDateTimeRange(afterDateTime, _sentBeforeDateTime);
_sentAfterDateTime = afterDateTime;
}
/// <summary>
/// Set a value which represents a date/time before which
/// messages must have been sent to be part of filtered output.
/// </summary>
/// <param name="beforeDateTime">The date/time before which
/// messages must have been sent to be part of filtered output.</param>
public void SetSentBeforeDateTime(DateTime beforeDateTime)
{
DateValidation.ValidateDateTimeRange(_sentAfterDateTime, beforeDateTime);
_sentBeforeDateTime = beforeDateTime;
}
По словам MSDN:
Чаще ArgumentException является Брошенный общий язык runtime или другую библиотеку классов и указывает ошибку разработчика.
Я получаю, что фраза «чаще всего» оставляет возможность открытой для других обычаев, как моя, но мне нравится придерживаться конвенции. Я создаю открытый API, поэтому исключение будет задокументировано и выйдет за пределы открытого интерфейса; кроме того, он не указывает на ошибку разработчика. Это может, предположительно, указывать на ошибку пользователя (это общепринятое соглашение об использовании исключений для решения проблем проверки входных данных пользователя). Я чувствую, основываясь на описании MSDN, однако, что это не то, для чего он предназначен.
... Производные классы [ArgumentNullException и ArgumentOutOfRangeException] должен быть использован вместо ArgumentException, за исключением того, в ситуациях, когда ни один из производных классов является приемлемым. Например, исключения должны быть брошено:
...
ArgumentOutOfRangeException, когда значение аргумента находится вне диапазона допустимых значений; например, когда значение «46» равно , принятое в качестве аргумента месяца при создании DateTime.
Мой аргумент может быть вне диапазона допустимых значений, но это условие определяется динамически на основе другого значения даты/времени. Нет статического диапазона значений, которые «вне диапазона».
Значит, ArgumentException обычно используется для таких случаев?
Я бы не согласился с утверждением: «Общим соглашением является использование исключений для решения проблем проверки ввода пользователя». Разработчик, который использует ваш API, отвечает за проверку ввода пользователя перед передачей его функции. Если пользователь предоставляет недопустимый ввод и разработчик не поймает его, прежде чем передавать его в вашу функцию, это «ошибка разработчика». –
Хорошая точка. Согласен. –
_ «Этот вопрос касается соглашения и интерпретации MSDN, поэтому я не думаю, что в первую очередь это основано на мнениях», - прося что-либо, кроме буквального чтения MSDN, вы, безусловно, задаете вопрос «в первую очередь мнение» , Конвенции, по определению, субъективны и даже там, где некоторая конвенция была документирована, если вы хотите, чтобы отдельные интерпретации этой документации выходили за рамки того, что буквально представлено в документации, это может быть также субъективным. –