Possible Duplicate:
Arguments for or against using Try/Catch as logical operators
Efficient try / catch block usage?

I was recently on a job interview and I was given a task to write simple method in C# to calculate when the trains meet. The code was simple mathematical equation. What I did was that I checked all the parameters on the beginning of the method to make sure, that the code will not fail.

My question is: Is it better to check the parameters, or use try/catch?

Here are my thoughts:

  • Try/catch is shorter
  • Try/catch will work always even if you forget about some condition
  • Catch is slow in .NET
  • Testing parameters is probably cleaner code (Exceptions should be exceptional)
  • Testing parameters gives you more control over return values

I would prefer testing parameters in methods longer than +/- 10 lines, but what do you think about using try/catch in simple methods just like this – i.e. return (a*b)/(c+d);

There are many similar questions on stackexchnage, but I am interested in this particular scenario.

  • 1
    And here is an even older duplicate: programmers.stackexchange.com/q/107723/15464 – Steven Jeuris Nov 30 '12 at 10:52
  • 1
    The fact that someone called your function with invalid arguments isn't exceptional? – unholysampler Nov 30 '12 at 14:57
  • It is, but passing c = 10 and d = -10 will go to division by zero, even if both paramers are correct. If you remove the abstraction, than c can be speed of train1 and d is speed of train2. Train2 is going backward (i.e. "-" = same direction as train1) and they will never meet. Is is logically correct, but mathematically it will fail. – Ondra Nov 30 '12 at 15:33

The general rule is indeed to test for fail conditions before continuing (possibly throwing an exception if the test fails).

Pretty much for the reasons you quoted above.

In terms of implementation, you can also cleanly separate the validation from the implementation (this is done very often in BCL code).


Try catch if you are relying on something external eg another service or a DB server.

Solely check the parameters if it's something internal as in the example.


It depends on how specific you want to be about the cause of the problem. If you test up front, you can raise an exception indicating precisely which inputs is in error. However, if you are performing floating-point computations, es careful examination of the method body is needed to determine which inputs are valid. This may not always be feasible. Your post does not fully express the complexity of your simple example:

(a * b) / (c + d)

It is not enough to simply test that c + d != 0. If these are floating-point numbers, you also have a possibility for overflow when a * b is much larger than c + d.

In numeric computations, it is often impossible to tell whether the inputs can produce a result without performing the computation.

Generally I prefer to write straight-line code and either allow exceptions to propagate, or else catch them and convert them to something meaningful to the caller.

I seldom worry about the slowness of language feature until there is a known performance problem.


Code Complete has a good chapter (8) on this.

The first question I'd ask is where is the input coming from. Is it coming from within the application (probably considered "sterile"), or is it coming from somewhere else (e.g. user input)?

I think you need to know the answer to that question in order to determine whether the inputs should be checked and how to handle what happens when they're invalid.

Not the answer you're looking for? Browse other questions tagged or ask your own question.