.NET: Which Exception to Throw When a Required Configuration Setting is Missing?

Here's a standard scenario:

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

The problem is, I am not entirely certain which exception SomeStandardException should be.

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

System.Configuration.ConfigurationException

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

Remarks

The ConfigurationException exception is thrown if the application attempts to read or write data to the configuration file but is unsuccessful. Some possible reasons for this can include malformed XML in the configuration file, file permission issues, and configuration properties with values that are not valid.

Note:

The ConfigurationException object is maintained for backward compatibility. The ConfigurationErrorsException object replaces it for the configuration system.

This exception actually sounds perfect for what I need, but it's been marked obsolete, so, ixnay on atthay.

This brings us to the thoroughly puzzling ConfigurationErrorsException:

System.Configuration.ConfigurationErrorsException

The current value is not one of the EnableSessionState values.

As you can see, its documentation is completely useless. (It's that way in both local and online help.) An examination of the class itself shows that it's drastic overkill for what I want.

In a nutshell, I need a standard exception that should be thrown when an application configuration setting is missing or contains an invalid value. You'd think the Framework had such an exception baked into it for applications to use. (It apparently did, but it was marked obsolete, and was replaced by something much larger in scope.)

What solutions, if any, are you guys using for this, and am I going to have to suck it up and roll my own exception for this?

Edit Addenda

Some have asked whether or not I could provide a default value, and continue. In certain cases, yes, and in those cases, the exception would not be thrown. However, for certain settings, this won't apply. For instance: database server names and credentials, authentication servers, and paths to installed third party applications.

It is also worth noting that the application I'm primarily working on is a console application running in batch mode, and I want it to throw an exception that is caught by the main method and logged appropriately if the thing isn't appropriately configured. (It's legacy code I've inherited, and currently just assumes everything's peachy.)

Personally, I'd use InvalidOperationException, as it's a problem with the object state - not the configuration system. After all, shouldn't you allow these settings to be set by code and not config as well? The important part here is not that there was no line in app.config, but that a required piece of info was not present.

To me, ConfigurationException (and it's replacement, ConfigurationErrorsException - despite the misleading MSDN docs) are for errors in saving, reading, etc. of Configuration.

You're not limited in your exception-throwing to existing exceptions in the Framework. If you do decide to use existing exceptions, you don't absolutely have to follow the documentation to the letter. The documentation will describe how the framework uses a given exception, but doesn't imply any limitation on how you choose to use/reuse an existing exception.

It's your application- as long as you document it and clearly indicate the exception that will be thrown in the specific case of a missing configuration value, you can use any exception you like. If you do want a very specific indication of a missing value, you might consider writing your own ConfigurationSettingMissing exception:

[Serializable]
public class ConfigurationMissingException : ConfigurationErrorsException
{}

EDIT: Writing your own exception in this case carries the added benefit of guaranteeing that there will never be any confusion regarding where the exception is coming from- the framework, or your application. The framework will never throw your custom exceptions.

UPDATE: I agree with the comments, so I have 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 unless you need an application-specific exception.