.NET: какое исключение создавать при отсутствии обязательного параметра конфигурации?

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

Это ваше приложение - пока вы его документируете и четко указываете исключение, которое будет выдано в конкретном случае отсутствующего значения конфигурации, вы можете использовать любое исключение, которое вам нравится. Если вам действительно нужна очень конкретная индикация отсутствующего значения, вы можете подумать о написании собственного исключения ConfigurationSettingMissing:

[Serializable]
public class ConfigurationMissingException : ConfigurationErrorsException
{}

РЕДАКТИРОВАТЬ: написание собственного исключения в этом случае дает дополнительное преимущество, гарантируя, что никогда не будет путаницы в отношении того, откуда исходит исключение - из фреймворка или вашего приложения. Фреймворк никогда не будет генерировать ваши пользовательские исключения.

ОБНОВЛЕНИЕ: я согласен с комментариями, поэтому я изменил подкласс на ConfigurationErrorsException из Exception. Я думаю, что обычно рекомендуется создавать подклассы пользовательских исключений из существующих исключений Framework, где это возможно, избегая класса Exception, если вам не требуется исключение для конкретного приложения.

Лично я бы использовал InvalidOperationException, поскольку это проблема с состояние объекта, а не система конфигурации. В конце концов, разве вы не должны позволять устанавливать эти параметры с помощью кода, а не конфигурации? Важная часть здесь не в том, что в app.config не было строки, а в том, что не было необходимой информации.

Для меня ConfigurationException (и его замена, ConfigurationErrorsException - несмотря на вводящие в заблуждение документы MSDN) предназначены для ошибок при сохранении, чтении и т. Д. Configuration.

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

До .NET 2.0 рекомендовалось использовать System.Configuration.ConfigurationException. ConfigurationException устарело в .NET 2.0 по причинам, которые никогда не были мне понятны, и рекомендация была изменена на использование ConfigurationErrorsException.

Я использую вспомогательный метод, чтобы генерировать исключение, чтобы было легко изменить исключение, генерируемое в одном месте при переходе с .NET 1.x на 2.0, или если Microsoft решит снова изменить рекомендацию:

if(string.IsNullOrEmpty(Configuration.AppSettings("foobar")))
{
   throw CreateMissingSettingException("foobar");
}

...

private static Exception CreateMissingSettingException(string name)
{
    return new ConfigurationErrorsException(
        String.Format
        (
        CultureInfo.CurrentCulture,
        Properties.Resources.MissingConfigSetting,
        name
        )
        );
}

А как насчет _1 _?

ConfigurationErrorsException - правильное исключение для описанной вами ситуации. Более ранняя версия документации MSDN для ConfigurationErrorsException имеет больше смысла.

http://msdn.microsoft.com/en-us/library/system.configuration.configurationerrorsexception(VS.80).aspx

Предыдущее резюме и примечания MSDN:

• Исключение, которое выдается при возникновении ошибки системы конфигурации.
• Исключение ConfigurationErrorsException выдается, когда возникает какая-либо ошибка во время чтения или записи информации о конфигурации.

Класс ConfigurationElement (который является базовым классом многих классов, связанных с конфигурацией, таких как ConfigurationSection) имеет метод OnRequiredPropertyNotFound (есть и другие вспомогательные методы). Вы можете их назвать.

OnRequiredPropertyNotFound реализован следующим образом:

protected virtual object OnRequiredPropertyNotFound(string name) {
    throw new ConfigurationErrorsException(SR.GetString("Config_base_required_attribute_missing", new object[] { name }), this.PropertyFileName(name), this.PropertyLineNumber(name)); }

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

в общем, кастомное исключение не требует больших усилий ... вот пример ...

[Serializable]
public class MyCustomApplicationException : ApplicationException
{
    #region privates
    #endregion privates

    #region properties
    #endregion properties

    public MyCustomApplicationException (string sMessage,
        Exception innerException)
        : base(sMessage, innerException) { }
    public MyCustomApplicationException (string sMessage)
        : base(sMessage) { }
    public MyCustomApplicationException () { }

    #region Serializeable Code
    public MyCustomApplicationException (
       SerializationInfo info, StreamingContext context)
        : base(info, context) { }
    #endregion Serializeable Code
}

Альтернативный метод, который вы могли бы использовать для своих файлов конфигурации, заключался бы в использовании настраиваемых разделов конфигурации вместо AppSettings. Таким образом вы можете указать, что свойство IsRequired и система конфигурации будут выполнять эту проверку за вас. Если свойство отсутствует, оно выдаст ConfigurationErrorsException, поэтому я полагаю, что это подтверждает ответ о том, что вы должны использовать это исключение в своем случае.

Мое общее правило было бы таким:

1. Если случай с отсутствующей конфигурацией не очень распространен, и я считаю, что никогда не хотел бы обрабатывать этот случай иначе, чем другие исключения, я просто использую базовый класс «Exception» с соответствующим сообщением:

   выбросить новое исключение («мое сообщение здесь»)

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

Я склонен не согласиться с предпосылкой вашего вопроса:

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

Согласно документации MSDN по System.Exception (Exception Class , вам действительно не следует генерировать исключения для ошибок ввода пользователя по причинам производительности (на что указали другие в Stack Overflow и в других местах). Это также имеет смысл - почему ваша функция не может вернуть false, если пользовательский ввод введен неправильно, а затем приложение корректно завершает работу? Это скорее проблема дизайна, чем проблема, с которой нужно создать исключение.

Как указывали другие, если вам действительно нужно выбросить исключение - по какой-либо причине - нет никаких причин, по которым вы не могли бы определить свой тип исключения путем наследования от System.Exception.

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