.NET: what exception should be thrown when the required configuration setting is missing?

Here's the standard scenario:

if(string.IsNullOrEmpty(Configuration.AppSettings["foobar"])) throw new SomeStandardException("Application not configured correctly, bozo."); 

The problem is that I'm not quite sure what exception should be SomeStandardException .

I looked through the 3.5 Framework and found two likely candidates: ConfigurationException and ConfigurationErrorsException .

System.Configuration.ConfigurationException

An exception that is thrown when a system configuration error has occurred.

Notes

A ConfigurationException if the application tries to read or write data to the configuration file, but to no avail. Some possible reasons for this may be incorrect XML in the configuration file, permission file, and configuration properties with values ​​that are not valid.

Note:

A ConfigurationException object is supported for backward compatibility. ConfigurationErrorsException object replaces it for configuration.

This exception is really perfect for what I need, but it was deprecated, therefore, ixnay at atthay.

This brings us to a completely cryptic ConfigurationErrorsException :

System.Configuration.ConfigurationErrorsException

The current value is not one of the EnableSessionState Values.

As you can see, its documentation is completely useless. (This is true in both local and online help.) Studying the class itself shows that this is a radical overflow for what I want.

In short, I need a standard exception that should be thrown if the application configuration parameter is missing or contains an invalid value. You might think that there is such an exception in the Framework that is baked in it for use by applications. (Apparently, this was done, but it was obsolete and was replaced by something larger in volume.)

What solutions, if any, do you guys use for this, and will I have to suck it and roll my exception for this?

Edit uploads

Some ask if I can provide a default value and continue. In some cases, yes, and in those cases an exception will not be thrown. However, for certain settings this will not apply. For example: database server names and credentials, authentication servers, and paths to installed third-party applications.

It is also worth noting that the application that I am working on first of all is a console application that runs in batch mode, and I want it to throw an exception that was caught by the main method and registered accordingly if the thing is not properly configured . (This is the legacy code I inherited, and currently just accepts all peach.)

+106
exception configuration
Jan 06 '09 at 16:23
source share
11 answers

You are not limited in your exceptions to exceptions to existing exceptions in the Framework. If you decide to use existing exceptions, you do not have to follow the documentation for the letter. The documentation will describe how the infrastructure uses this exception, but does not imply any restrictions on how you decide to use / reuse the existing exception.

This is your application - while you document it and clearly indicate the exception that will be selected in the specific case of the missing configuration value, you can use any exception that you like. If you need a very specific indication of the missing value, you might consider creating your own ConfigurationSettingMissing exception:

 [Serializable] public class ConfigurationMissingException : ConfigurationErrorsException {} 

EDIT: Writing your own exception in this case has the added benefit of ensuring that there will never be any confusion as to where the exception comes from - the framework or your application. The framework will never throw your custom exceptions.

UPDATE: I agree with the comments, so I changed the subclass to ConfigurationErrorsException from Exception. I think it's generally a good idea to subclass custom exceptions from existing Framework exceptions, where possible, avoiding the Exception class if you don't need an exception for a particular program.

+29
Jan 06 '09 at 16:29
source share

Personally, I used an InvalidOperationException , since this is a problem with the state of the object, and not with the configuration system. After all, shouldn't you let these settings set the code and not set it up? The important part here is not that there was no line in app.config, but there was no necessary information in it.

To me, ConfigurationException (and its replacement, ConfigurationErrorsException - despite the misleading MSDN documents) refer to errors in saving, reading, etc. Configurations.

+39
Jan 06 '09 at 16:32
source share

As Daniel Richardson said, a ConfigurationErrorsException is the one to use. In general, it is recommended that you create your own types of exceptions if you have a script to handle them. In the case of configuration errors that are usually fatal, this is rarely the case, so it is usually more advisable to reuse the existing ConfigurationErrorsException type.

Prior to .NET 2.0, it is recommended that you use a System.Configuration.ConfigurationException . A ConfigurationException became deprecated in .NET 2.0 for reasons that were never clear to me, and the recommendation changed to using a ConfigurationErrorsException.

I use a helper method to throw an exception so that it is easy to change the exception that was selected in one place when porting from .NET 1.x to 2.0, or Microsoft decided to change the recommendation again:

 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 ) ); } 
+17
Jan 6 '09 at 17:23
source share
+14
May 05 '09 at 12:11
source share

ConfigurationErrorsException is the correct exception to throw in the described situation. An earlier version of the MSDN documentation for ConfigurationErrorsException makes more sense.

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

Earlier posts and MSDN notes:

  • An exception that is thrown when a system configuration error has occurred.
  • A ConfigurationErrorsException exception is thrown when any error occurs while configuring information being read or written.
+8
Jan 06 '09 at 17:09
source share

The ConfigurationElement class (which is the base class of many configuration-related classes, such as ConfigurationSection) has an OnRequiredPropertyNotFound method (there are other helper methods). You can call them.

OnRequiredPropertyNotFound is executed as follows:

 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)); } 
+5
Jan 06 '09 at 16:33
source share

I would suck it and drop it myself ... but before you do this, is it possible for the system to accept the default value for this setting? Usually I try to do this for every setting that might be skipped if you have experience managing Ops Management operations ... (or maybe I should say that for as many parameters as possible - for some it’s clearly not suitable for the system made the decision by default ...)

in general, the usual exception is not a lot of effort ... here's an example ...

 [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 } 
+1
Jan 6 '09 at 16:27
source share

An alternative method that you could use for your configuration files would be to use custom configuration sections rather than AppSettings . This way you can specify that the IsRequired property and the configuration system will handle this check for you. If the property is missing, it will throw a ConfigurationErrorsException , so I suppose it supports the answer that you should use this exception in your case.

+1
Jul 08 2018-11-11T00:
source share

My general rule:

  • If the situation with the missing configuration is not very common, and I believe that I would never want to handle this case other than other exceptions, I just use the base class "Exception" with the corresponding message:

    throw new Exception ("my message is here")

  • If I really want or think that with a high probability I would like to handle this case in a different way than most of the other exceptions, I would throw my own type, as people have said here.

0
Jan 06 '09 at 16:36
source share

I tend to disagree with the premise of your question:

In short, I need a standard exception that should be thrown if the application configuration parameter is missing or contains an invalid value. You might think that there is such an exception in the Framework that is baked in it for use by applications. (Apparently, this was done, but it was obsolete and was replaced by something larger in volume.)

According to the MSDN documentation in System.Exception ( Exception Class, you really should not throw exceptions for user input errors, for (which was pointed out by others in relation and elsewhere). It also makes sense - why your function does not return false if incorrect user input is entered, and after that the application exits gracefully? It seems more like a design problem, but a problem that throws an exception.

As others have pointed out, if you really have to throw an exception - for any reason - there is no reason why you could not define your type of exception by inheriting from System.Exception.

0
Jan 6 '09 at 16:36
source share

You can try to inherit the XML exception or just use it.

-2
Jan 06 '09 at 16:28
source share



All Articles