What Exception Type to throw for strings

Question

If I've got the following, really for any string where you check IsNullOrEmpty and it turns up empty, what kind of exception type should one throw, and it's not a argument to a method?

I always have a hard time picking exception types because there are so damn many of them. And this is just grabbing a value from the web.config and checking if SandboxSoapApiUsername returned empty.

if(string.IsNullOrEmpty(ConfigUtility.SandboxSoapApiUsername))
        throw new WTF do I throw here??? ahhh

It probably depends on the use/context right? Well I will use the string returned to set a class private field. So I need to check if it's empty string early in the process rather than later (rather than rely on other code to check the property related to the private field I will set ConfigUtility.SandboxSoapApiUsername to).

Since the properties in this class that I'm setting each ConfigUtility.MEthodName to is going to be used in a SOAP request I thought maybe UriFormatException would be appropriate here even though this is not the Uri?

Answer 1

It depends when the string comes from. An argument might cause an ArgumentNullException. Configuration might throw a ConfigurationException (which seems to be applicable to this case). Or you can of course create your own anyway.

Answer 2

If its passed as an argument, throw ArgumentNullException.

Otherwise, it really depends on what the string being null means in the context of your application. Don't be afraid to define custom Exception types if there isn't something in the base framework for the scenario.

Answer 3

Methods in the .NET Framework usually distinguish between null and an invalid value passed in for an argument. I think you should throw an Argument​Null​Exception if the value is null and an Argument​Exception if it's invalid.

if (arg == null)
    throw new ArgumentNullException("arg", "argcannot be null");
if (arg == string.Empty)
    throw new ArgumentException("arg cannot be an empty string", "arg");

If the value is not an argument, but, for example, loaded during initialization, I think a Invalid​Operation​Exception would be appropriate:

if (string.IsNullOrEmpty(ConfigUtility.SandboxSoapApiUsername))
    throw new InvalidOperationException("Cannot initialize because " +
                                        "SandboxSoapApiUsername not configured");

Answer 4

you need an InvalidConfiguration exception - define one

 throw new InvalidConfigurationException("Must supply user name")

Answer 5

Since it seems something wasn't configured correctly, I'd suggest System.Configuration.ConfigurationErrorsException.

Note: don't use System.Configuration.ConfigurationException. It's an older version and has been deprecated.

Note 2: Though I'm 90% sure we're dealing with a missing configuration value, if it's an method parameter that's missing, throw an ArgumentException or ArgumentOutOfRangeException.

Answer 6

You will really spend most of your time picking from of the list below when throwing a new exception (as opposed to simply doing a throw).

1. ConfigurationException
   • The exception that is thrown when a configuration system error has occurred.
2. ArgumentException
   • The exception that is thrown when one of the arguments provided to a method is not valid.
3. InvalidOperationException
   • The exception that is thrown when a method call is invalid for the object's current state.

1)
This arguably doesn't make sense unless you're picking the setting from an app.config or web.config:

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.

2)
It's not an argument so this one doesn't make much sense.

3)
This is the best of the three as the object will be in an invalid state. However depending on how big your set of configuration settings is, I would prefer to make my own Exception derived from System.Exception.

There's two schools of thought about which to derive from - System.Exception and ApplicationException*. Two different developers on the framework team have expressed different views on which they think you should inherit from, I stick with Jeffrey Richter's view.

If all the above sounds like woffle, then you could just pick one you think is most relevant from the list.

^{*Looks like MSDN now agrees with its framework devs that ApplicationException was a design mistake}