It's Not How You Throw It, It's What You Throw

Now that you have a understanding of what an exception is and why you use one, let's talk about proper exception throwing.

You throw an ArgumentException exception (or an exception that inherits from ArgumentException) when a parameter that is passed to a method violates the method's implicit assumptions or expectations. The example below shows a user-defined method, GetPriceToEarningsRatio(). GetPriceToEarningsRatio() takes two arguments, PricePerShare and EarningsPerShare. GetPriceToEarningsRatio() returns the price to earning ratio of a given stock.

Consumers of GetPriceToEarningsRatio() really have no idea how the method determines the ratio, because the internal workings of the method are hidden. (It's an object oriented programming thing.) For all we know, the method could be calling a Web site in Las Vegas that makes up the ratio based on some sort of magically algorithm. However, internally within the method, the reality is that the price to earnings ratio is determined by dividing the price per share by the earnings per share.

Now, if you think back to your sixth grade arithmetic class you will remember that it is erroneous to divide a number by zero. Thus, if the argument, EarningsPerShare is zero, it violates the method's assumption that EarningsPerShare should not be zero and an ArgumentException exception is thrown. (Please see Listing 5.)

Listing 5: A C# example

private decimal GetPriceToEarningsRatio(double PricePerShare, double EarningsPerShare)
{
    if(EarningsPerShare ==0)
    {
    throw new InvalidArgumentException("EarningsPerShare must be a non-zero number")
    }
    return Price/ Earnings
SS}

In the example above, you might ask why not just let the divide-by-zero error happen? Why intercept the error and throw it as an ArgumentException? After all, .NET does provide a DivideByZeroException.

The reason is that one of the arguments is not valid for the method GetPriceToEarningsRatio(), not that there is a divide by zero exception. Those looking at the method from the "outside" have really no idea what the divide-by-zero means, why it was thrown, or how to correct the error. Again, for all the consumer of the method knows the ratio, could be determined by magical divination.

In the future, we may change the implementation of how the ratio is defined. Throwing an ArgumentException rather than a DivideByZeroException means the caller doesn't have to change its exception handling when the underlying implementation changes.

However, throwing an ArgumentException, and providing an exception message (you can construct an ArgumentException to contain a message) lets the user of the method know that something is wrong with an argument, and that the value of an argument needs to be corrected.

Knowing how an application handles a given exception is not something that is of concern to the method throwing the exception. The job of the method throwing the exception is to provide enough information to tell the method consumer what the problem is and to offer a way to correct it.