Exception handling Try-Catch block difference

Question

I know, we can use try-catch block to handle exceptions. But I have some doubts in the usage of Try-Catch. What is the difference between

   try
   {
      //Some code
   }
   catch
   {

   }

and

   try
   {
    //Some code
   }
   catch(Exception)
   {

   }

and

   try
   {
    //Some code
   }
   catch(Exception oops)
   {

   }

In my program, I need to catch all exceptions and I don't want to log them. From the above mentioned Try-Catch blocks, which should be used?

The last one, I would prefer. Though the first and last both work. Don't know about the middle; I haven't seen that anywhere. — , Apr 08 '13 at 08:29
possible duplicate of [the difference between try/catch/throw and try/catch(e)/throw e](http://stackoverflow.com/questions/1697216/the-difference-between-try-catch-throw-and-try-catche-throw-e) — Iswanto San, Apr 08 '13 at 08:29

Andy · Answer 1 · 2013-04-08T08:44:52.680

2

So far you use catch (Exception), the first and the second are the same. You catch everything in this case. When you like to catch a specific exception like UnauthorizedAccessException, you have to use the second one like this:

try
{
    //Some code
}
catch (UnauthorizedAccessException)
{
    MessageBox.Show(oops.Message);
}

In the third case you can use the Exception through the variable oops.

For example:

try
{
    //Some code
}
catch (Exception oops)
{
    MessageBox.Show(oops.Message);
}

Or with a specific exception:

try
{
    //Some code
}
catch (UnauthorizedAccessException oops)
{
    MessageBox.Show(oops.Message);
}

edited Apr 08 '13 at 08:44

answered Apr 08 '13 at 08:29

Andy

3,997
2
19
39

1

The first and second aren't **always** the same – LukeHennerley Apr 08 '13 at 08:31
Can you explain any example? – Andy Apr 08 '13 at 08:34
1

Yes - if you change the type of exception your catching in your block it will not catch all exceptions. You tend to catch specific, expected types of exceptions in best code practices. See my answer for an example :) – LukeHennerley Apr 08 '13 at 08:36
Thank you. Seems my post was a bit confusing, I just referred to `catch (Exception)` and nothing else. Edited :) – Andy Apr 08 '13 at 08:45

Guffa · Accepted Answer · 2013-04-08T08:40:32.027

Using a catch without a parameter is no longer useful as of framework 2.0, as all unmanaged exceptions are wrapped in a managed exception. Before that you could use it to catch exceptions thrown by unmanaged code.

You can specify just the type of the exception if you don't want to use any information from it, but usually you would want a name for it so that you can get to the information:

try {
  // some code
} catch(Exception) {
  // i don't care about any information in the Exception object, just the type
}

vs.

try {
  // some code
} catch(Exception ex) {
  // use some information from the exception:
  MessageBox.Show("Internal error", ex.Message);
}

You should always try to have an exception type that is as specific as possible, as that makes it easier to handle the exception. Then you can add less specific types to handle other exceptions. Example:

try {
  // some database code
} catch(SqlException ex) {
  // something in the database call went wrong
} catch(Exception ex) {
  // something else went wrong
}

score 1 · Answer 3 · answered Apr 08 '13 at 08:30

Generic try catch, this will catch any type of exception

try
{
   //Some code
}
catch
{

}

This will catch the specific type of exception that you specify, you can specify multiple.

try
{

}
catch (UnauthorizedAccessException)
{

}

This will do the same as above but give you a variable that has access to the properties of an exception.

try
{

}
catch (UnauthorizedAccessException ex)
{

}

score 0 · Answer 4 · answered Apr 08 '13 at 08:29

0

You should be using the last one, and handling in a clean way your exception.

The first too way are the same but are "Eating Exceptions", witch is the worst thing to do.

At least log your exception!

answered Apr 08 '13 at 08:29

Thomas

5,603
5
32
48

To be honest, he shouldn't be using **any**. It's bad design, you should only catch *specific* exceptions you intend to handle, it's generally never a good idea to do a catch-all. – James Apr 08 '13 at 08:39
I think you are rigth. If someone come to you and ask you "I want to cut my arm, how can I do that?". What should you answer? Yes I think @Kaizen should not do that, but is question was not "is it a good idea to do that", so ... What Should we do? What would Mo do? – Thomas Apr 08 '13 at 08:46
You give the *technical* answer of how you do it then in big bold writing say *why* they shouldn't. – James Apr 08 '13 at 10:09

James · Answer 5 · 2013-04-08T08:35:52.800

They are all pretty much the same (I assume the first is shorthand for writing the 2nd), the difference with the last is you are putting the exception object into a variable so you can use it in the catch.

Usually when I see code like this I tend to worry as it's generally not a good idea as you could be masking bigger problems with your application.

Rule of thumb - handle what you can, let everything else bubble up.

score 0 · Answer 6 · answered Apr 08 '13 at 08:29

0

Your first and second example are the same. They will both catch any exception, without any information about the exception. The third exception stores the exception in oops, which you can then use to get more information about the exception.

answered Apr 08 '13 at 08:29

John Willemse

6,608
7
31
45

score 0 · Answer 7 · answered Apr 08 '13 at 08:31

0

Look at msdn documentation: http://msdn.microsoft.com/en-us/library/vstudio/0yd65esw.aspx

The best is specify which kind of errors you would like catch.

answered Apr 08 '13 at 08:31

Ryba

171
7

score 0 · Answer 8 · answered Apr 08 '13 at 08:34

The third one is the best...

You can catch any kind of specific exception and it will be precise... This helps in identifying the exact exception and easy for us to correct them as well

For eg: one can catch DivisionByZeroException, TargetInvocationException, ArrayOutOfBoundException, etc...

score 0 · Answer 9 · answered Apr 08 '13 at 08:46

i think it has the same function - To trace where the error is set/ or where did something get wrong,

using try-catch this way

> try {

//some codes 
 }

catch
{
//anything
//e.g.:
MessageBox.Show("Something is wrong!");
}

this tells the that there is something wrong but didn't show the detailed report. (Clever way to hide some errors is don't put anything in the catch{} xD, but this is not advised to do)

the next is to show detailed report of the error

try
{
//some codes
}

catch (Exception ex)
{
MessageBox.Show(ex.ToString());
}

hope this helps! :D

Exception handling Try-Catch block difference

9 Answers9