Is it a good or bad idea throwing Exceptions when validating data?

Question

Hi,

When validating data, I've gotten into a habit of doing the following

*Note: i dont really have individual booleans for each check. This is just for the example.

*Another Note: any error handling during the tests are done properly. The ONLY exceptions thrown in the try-catch are my own.

Try
{

  if(validCheckOne = false)
  { throw new Exception("Check one is bad"); }

  if(validCheckTwo = false)
  { throw new Exception("Fail'D because of check2"); }

  if(validCheckTen = false)
  { throw new Exception("Yet another failure on your part: check10."); }

}
catch(Exception e)
{
  MessageBox.Show("Your stupid data is wrong! See for yourself: " + e.Message);
}

Is this bad practice? Does throwing Exceptions slow the program's execution or is inadvisable?

Answer 1

I'm going to repeat the mantra here: throwing exceptions should be done in exceptional circumstances. Invalid entered data is really not that exceptional.

Answer 2

This is bad behavior. Exceptions are for Exceptional conditions. They take resources to generate the stack etc. Exceptions should not be used to dictate process flow.

Answer 3

It depends - if you are expecting the data to be there and NOT having the data is unexpected, then throwing an exception is OK. Throwing an exception is very expensive (slow) but is the best way to handle unexpected circumstances.

Answer 4

I support MusiGenesis's answer.

Additionally...

---

The performance of throwing an exception is a thousand instructions. It's nothing compared to end-user time, but in inner code it is slow.

An additional problem is that, using Exceptions, your validation is limited to reporting the first failure (and you will have to do it all again next time to find the next failure).

Answer 5

In general it is inadvisable to use Exceptions to implement conditional flow. It would be better to do something like this

  error = false;
  while(true) {
    if(validCheckOne == false) { 
       msg = "Check one is bad"; 
       error = true;
       break;
    }

    if(validCheckTwo == false) { 
       msg = "Check two is bad"; 
       error = true;
       break;
    }
    ...
    break;
  }
  if (error) {
     ..
  }

You should throw an exception when there is a situation you can't do nothing about it. Higher layers of software would have a chance to catch the exception and do something about it - even if that is simply crashing the application.

Answer 6

It really only matters if your data validation is in a tight loop. For most cases, it doesn't matter what you choose as long as you are consistent in your code.

If you have a lot of code that looks like your sample above then you might want to clean it up by introducing a helper method to throw...

private void throwIf( bool condition, String message )
{
    if( condition )
        throw new ApplicationException( message );
}

(also, doing this will help zero in on errors such as "validCheckOne = false" versus "validCheckOne == false" :)

Answer 7

In addition to the oft-repeated statement that "exceptions are for exceptional circumstances", here's an additionally clarifying rule I've come to like:

If the user caused it, it's not exceptional.

Exceptions are for system-side things (servers going down, resources being unavailable), not for the user doing odd things, because all users do odd things.

Answer 8

Personally I like throwing Exceptions for business rule validation (not so much for user input validation) because it forces the problem to be handled upstream. If my business objects returned some kind of validation result, it could be ignored by the caller. Call me a cowboy if you wish :)

Everyone here is repeating the phrase "exceptions are for exceptional circumstances", but that really doesn't give any understanding of why its bad to use them for unexceptional circumstances. I need more than that. Is the performance hit of throwing exceptions really that bad? Are there any benchmarks available?

Answer 9

I generally agree with the "exceptions should be exceptional" rule, but I might make an exception (ha!) for Python, where it can be both efficient and considered good practice to use try ... except to control flow.

See Using Exceptions For Other Purposes, for example.

Answer 10

So maybe in some languages exception throwing and catching is "costly" but in other languages, throwing and catching exceptions is exactly what's called for.

In Smalltalk, for example, one could quickly build a multi-tiered exception catching solution. The validation pass could collect up any number of exceptions representing EVERYTHING that's wrong with a particular input data set. Then it would throw them ALL up to a higher-level catcher, responsible for formatting up a human-readable explanation of, again, EVERYTHING that was wrong with the input. In turn it would throw a single exception further up the chain, along with that formatted explanation.

So... I guess what I'm saying is, exceptions are only bad to throw if you've got no exception handling architecture supporting catching them and doing reasonable things with them, and all your catcher is going to do is EXIT or do something else equally inappropriate.