Question

Why is it preferable to throw this Exception

Throw New DivideByZeroException("You can't divide by zero")

over this general one:

Throw New Exception("You can't divide by zero")

What advantage is gained in this particular example? The message already tell it all. Do standard subclasses that inherit from the base Exception class ever have different methods that the base? I haven’t seen a case, but I must admit that I tend to throw the base Exception.

Answer 1

The type of the exception allows handlers of the exception to filter it. If all you threw were exceptions of type Exception how would handlers know what exceptions to catch and which to allow to propagate up the call stack?

For example, if you always throw Exception:

void Foo(string item) {
  try {
    if (Bar(item)) { 
      Console.WriteLine("BAR!");
    }
  } catch (Exception e) {
    Console.WriteLine("Something bad?");
  }
}

bool Bar(string item) {
  if (item == null) {
    throw new Exception("Argument is null!");
  }

  return Int32.Parse(item) != 0;
}

How does the caller Foo know if a null exception occurred or if the Int32.Parse() failed? It has to check the type of the thrown exception (or do some nasty string comparison).

It’s even more worrisome if you get a ThreadAbortException or OutOfMemoryException which can occur in spots you wouldn’t expect an exception. In these cases if your catching code only catches Exception you may mask these (important) exceptions and cause damage to your program (or system) state.

The example code should read:

void Foo(string item) {
  try {
    if (Bar(item)) { 
      Console.WriteLine("BAR!");
    }
  } catch (ArgumentNullException ae) {
    Console.WriteLine("Null strings cannot be passed!");
  } catch (FormatException fe) {
    Console.WriteLine("Please enter a valid integer!");
  }
}

bool Bar(string item) {
  if (item == null) {
    throw new ArgumentNullException("item");
  }

  return Int32.Parse(item) != 0;
}