If try-catch can be replaced by if-then-else, which one is recommended?

Question

In my rough investigation, I think any errors can be handled by using if-then-else construct. Let's take a simple example as follows.

Division by zero can be handled with

int x=1;
int y=0;
if(y==0)
    Console.WriteLine("undefined");
else
    Console.WriteLine("x/y={0}",x/y);

to replace the try-catch equivalent

int x=1;
int y=0;
try
{
    Console.WriteLine("x/y={0}",x/y);
}
catch
{
    Console.WriteLine("undefined");
}

If try-catch can be replaced by if-then-else, which one is recommended?

When you have a large code base and a debugger that can break on all exceptions, you really want only exceptional circumstances to cause exceptions, or the real cause of problems may be hard to locate. — Joachim Isaksson, Sep 20 '13 at 04:27
Maybe you find this interessting: [Vexing exceptions](http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx) — sloth, Sep 20 '13 at 07:02
*I think any errors can be handled by using if-then-else construct*: Say you read data over a network connection (or simply copy a big file), and while you read the data, the network goes down. How do you handle this error using if-then-else construct? :-) — sloth, Sep 20 '13 at 07:06
@DominicKexel: We can check whether or not we are still connected to the network. :-) — kiss my armpit, Sep 20 '13 at 07:10
@PGFTricks Really? What happens when the network goes down *after* you checked that you're connected but *before* reading the next chunk of data? Or when the network goes down *while* you're reading? You have to be prepared to handle this *exceptional* situation :-) — sloth, Sep 20 '13 at 07:13
@DominicKexel: If we cannot read the next chuck, I think the read method should return a value such as `-1`, for example, to indicate this disconnection. I am not sure whether it is possible because I don't know how it works behind the scene. :-) — kiss my armpit, Sep 20 '13 at 07:18
@PGFTricks: Assume you write a method which calculates x/y, and it returns the result as an integer. Now it returns -1, how do you know if a correct calculation, or an error happened? — Kai Hartmann, Sep 20 '13 at 09:36

Renan Ranelli · Answer 1 · 2013-09-21T04:12:40.630

You should never use exceptions for flow of control. Exceptions should be "exceptional". If you know the rules for some data validation, you should use normal if/then/elses.

If you are doing some operation that can go wrong multiple ways (like connecting to a db) you should put that operation into a try-catch block and act accordingly.

Alas, the choice to treat something as "exceptional" goes into the designer's judgement.

EDIT: Also, do not underestimate the power of logging. Since I started using logging frameworks, my debugging time got cut by half.

plalx · Answer 2 · 2013-09-20T04:36:04.750

Not all errors for the simple reason that there are some unexpected errors and this is where you want to use a try-catch statement. However, it isin't a good practice to use try-catch for things that you can prevent going wrong.

Additionnaly, I would only catch exceptions that I know how to handle or that can be handled, otherwise you will be blindly swallowing every exceptions and your application will be extremely hard to debug.

However, if you don't know how to handle an exception but you know that your application can recover from an error in that portion of code and want to avoid your application to crash because of an unhandled exception, it could by fine to use a try-catch block, but it would also be a good idea to log the exception details.

score 1 · Answer 3 · edited Sep 06 '14 at 04:09

The block TRY..CATCH does not replace IF..ELSE! They are two diffeent things.

The TRY..CATCH block catches errors, if ever there is one, whereas the IF..ELSE is a condition. If the 1st condition is false, it'll execute the ELSE part.

The best practice however would be to use the two;

try
{
  if(y==0) 
  {
    Console.WriteLine("undefined");
  }
  else
  {
    Console.WriteLine("x/y={0}",x/y);     
  }
}
catch (Exception ex)
{
    Console.WriteLine("Error" + ex);
}

In this case here, if y was declared as Date for example, the condition would throw an error as (y==0) won't be evaluated. Thus sending you to the CATCH, which will throw you the conversion type error.

On the other hand, if y is declared as int (as in your example), there's not error evaluating (y==0) and hence, the IF..ELSE block will be executed.

BizApps · Answer 4 · 2013-09-20T04:37:11.577

1

You can use both.

Without try catch it is hard to find what specific error your code throws.

try
{
    int x=1;
    int y=0;
    if(y==0)
    Console.WriteLine("undefined");
    else
    Console.WriteLine("x/y={0}",x/y);
}
catch
{
    Console.WriteLine("undefined");
}

Best Regards

edited Sep 20 '13 at 04:37

answered Sep 20 '13 at 04:28

BizApps

5,924
7
37
59

So my `Main` method so be immediately followed by `try` block to anticipate all possible errors? – kiss my armpit Sep 20 '13 at 04:30
2

Generic catch blocks are usually a code smell. It's best to only catch exceptions you are prepared to deal with. Do you want to output "undefined" when `OutOfMemoryException` happens? Swallowing exceptions can also make bugs hard to track down, `catch {}` makes my blood boil :) – Matt Greer Sep 20 '13 at 04:32
I agree with Matt Greer. Please do NOT try to catch everything. In fact, a good application typically only handles exceptions at the bottom of each stack call. See this interview with Anders Hejlsberg, the father of C#: http://www.artima.com/intv/handcuffs2.html – musical_coder Sep 20 '13 at 04:36

score 1 · Answer 5 · answered Sep 20 '13 at 04:30

The try-catch block is the most efficient measure when it comes to Exception Handling. Here in this you are talking about a very simple and basic example, but there are lot many cases in the programming when there are multiple errors or exceptionn that could be found to a single expression. It is always prefer to go with (try-catch) block instead of checking for each condition.

score 1 · Answer 6 · answered Sep 20 '13 at 04:36

Because you don't alawys simply want to communicate an error by simply spewing data to the console. That is usually the course of last resort.

typically, you want to develop a structured error handling system. One notable featured of a structured system like this is is the ability to communicate an error condition to the caller of a function or procedure. in this instance if the caller is aware that there may be esceptional circumstances and is prepared to deal with this error communication from the callee, it is done so.

howeer, exception have a special property , that they will continue to exist as long as they are uncaught, going further and further back up the chain of callers until the 'signal' , the error, they represent is handled.

many times, errors ( exceptions ) ARE caught and dealt with ( handled ) without sending anything to the console.

The up-chaining, propagating exception system provides a baked-in-the-compiler , syntactically clean way of providing structured error handling.

error codes or signals can also be used for this purpose, but are not quite as syntactically smooth, and leave a lot of traces in the coding, of there being a lot of error handling code. Exceptions try to hide error handling, except where it is absolutely necessary, by using the compiler and runtime to keep track of error code status automatially.

score 1 · Answer 7 · answered Sep 20 '13 at 04:42

I wanted to add to this another important reason why in C# and many languages it's bad practice.

It's slow!

I had a situation where I was using try catch for flow control early on and it took about 15 ms to process the catch, where when I re-wrote it into a if-then statement it only took 1 ms when it hit the else (the catch). Some other languages are very efficient at try catch such as python and can use them in unique ways that C# should never do.

score 1 · Answer 8 · answered Sep 20 '13 at 05:08

try catch is efficient in large or small codes because when you put your code that you think maybe error occurred in this section of code . and then you catch the exceptions of your code if it occurred in run time. and if you want run a line of code that is important for running like you want to call GC or handle your memory allocation and free it and etc, you can put these codes in finally section and its completely support all type of code .and its a good way for exception handling.

try{code that you think maybe error occurred }
catch {if error or exception occurred how handle it }
finally{all code that you want run when program has exception or has not }

score 1 · Answer 9 · edited May 23 '17 at 11:50

1

The try catch in your case does not process the same logic as your if statement. You just implicitly assume it does. y == 0 is totally different from assuming that the only error which might occur is when y is 0. So basically a programmer does not know for sure what might cause the branching code. See also this article, which states, that using try-catch for flow control violates the 'principle of least astonishment': Why not use exceptions as regular flow of control?

edited May 23 '17 at 11:50

Community

1
1

answered Sep 20 '13 at 06:28

Kai Hartmann

2,876
25
38

I realized I got the question wrong. My answer relates to if a try-catch can replace an if-else. The other way around is aboslutely not possible. You cannot handle any occuring exception by if-else, you have to know beforehand what causes the error, and prevent it; and that is what is done by the OP. – Kai Hartmann Sep 20 '13 at 09:28

score -3 · Answer 10 · answered Sep 20 '13 at 06:47

-3

Using Try/Catch block is the best way since through exception management we can LOG these errors into any file OR we can throw this exception to the parent function within the application. Also any new programmer also can understand the code more clearly since you have used try/catch blocks.

Thanks, Skyrim.

answered Sep 20 '13 at 06:47

Skyrim

154
1
12

I would assume the opposite regarding understandability. – Kai Hartmann Sep 20 '13 at 07:23
Why is it beneficial to allow a program to go into an Exception state? Exceptions are very costly to throw at runtime. If the error is able to be detected by the current method and handled at that level, then there is no need to bubble an exception to the call site of the method. In general we should only catch exceptions we intend to handle. Logging and re-throwing an exception is not handling it. – mckeejm Sep 06 '14 at 04:50

If try-catch can be replaced by if-then-else, which one is recommended?

10 Answers10