C# 'try catch' syntax question

Question

Hi, a quick question about try / catch syntaxing...  Is it possible to have one catch statement catch multiple exception types, and if so what is the syntax?  Here's an example of what I'm trying to do: 

Code Snippet

try

{

  //

  // do some stuff here

  //

}

catch (DirectoryNotFoundException ex)

{

  MessageBox.Show("Unable to find files!");

}

catch (FileNotFoundException ex2)

{

  MessageBox.Show("Unable to find files!");

}

catch (Exception ex3)

{

  MessageBox.Show("Unable to find files!");

}

 

 

As you can see, the above code handles three exception types with the exact same result... how can I put them all in one catch {} block?? As in: 

Code Snippet

try

{

  //

  // do some stuff here

  //

}

catch (DirectoryNotFoundException, FileNotFoundException, Exception ex)

{

  MessageBox.Show("Unable to find files!");

}

 

 

Answer 1

No, you can't with C#.  You can only catch a base exception before derived exceptions.  For example:

Code Snippet

 try
 {
 }
 catch(ArgumentNullException ane)
 {

// do something with this specific ArgumentException-derived exception
 }
 catch(ArgumentException ae) 
 {

// do something with all the other ArgumentException-derived exceptions
 }

 

You must catch specific exceptions before the general exceptions (i.e. the derived before the base) otherwise you get a compile error because the derived are technically already handled.

 

 

Answer 2

Alright, thanks for the answer.

Answer 3

 

it would be nice though.

Answer 4

FelixWatts wrote:

it would be nice though.

I agree!

Answer 5

Actually, I believe the question was over-analyzed and the answer is yes. Just define one catch block that catches all errors of the base type Exception. The following code snippet will catch any exception that occurs in the try block.

 

Code Block

try

{

  //

  // do some stuff here

  //

}

catch (Exception ex)

{

  MessageBox.Show("Unable to find files!");

}

 

 

 

If you need to find out if it was a particular Exception type and gather its associated information, you could try casting it (using is) as certain Exception types and use it's related properties.

Code Block

try

{

  //

  // do some stuff here

  //

}

catch (Exception e)

{

  if (e is FileNotFoundException)

    Console.WriteLine("FileNotFound error: {0}", ((FileNotFoundException)e).FileName);

  else

    Console.WriteLine("Exception error: {0}", e.Message);

}

 

Good luck!

Answer 6

Davin Mickelson wrote:

Actually, I believe the question was over-analyzed and the answer is yes. Just define one catch block that catches all errors of the base type Exception.

That was pointed out in July.

Answer 7

David,

 

while your suggestion does work (just as well as catching separate exceptions in separate catch blocks and calling the same method in each block), it doesnt actually make the code neat, which is the point of the suggestion.

Answer 8

Peter - in July, you answered no, not yes. Your answer correctly stated how the order of the catch handers must be based on their inheritance (derived before base) but it didn't address the original question "Is it possible to have one catch statement catch multiple exception types, and if so what is the syntax?"

 

Felix - the original question was not about making the code "neat" but about creating one catch block that can handle multiple exception types.

 

BTW - VB doesn't raise an error if your catch blocks are in the wrong order. As of .NET 2.0, we now get a VB compiler warning message.

 

Sorry, guys - I must be totally missing something on this. Please tell me where I'm wrong.

Answer 9

maybe I misread the originl post, the goal that brought me to this thread was neatness.

 Since you can have

 

int a, b, c;

 

why cant you have

 

catch(SecurityException, UnauthorizedAccessException ex)

{...}

 

thats all

Answer 10

Davin Mickelson wrote:

Peter - in July, you answered no, not yes. Your answer correctly stated how the order of the catch handers must be based on their inheritance (derived before base) but it didn't address the original question "Is it possible to have one catch statement catch multiple exception types, and if so what is the syntax?"

No to not being able to specify multiple exceptions types in one block.  There was obviously an implied yes in being able to catch multiple types in one block should the block specific a base exception type... [edit] to which the OP marked the response as the answer.[/edit]

 

BTW, it's not recommended to create an exception hierarchy that would facilitate doing what the OP wants.

Answer 11

FelixWatts wrote:

maybe I misread the originl post, the goal that brought me to this thread was neatness.  Since you can have   int a, b, c;   why cant you have   catch(SecurityException, UnauthorizedAccessException ex) {...}   thats all

What do you expect to happen when you do this:

Code Block

try

{

//...

}

catch( SecurityException, UnathorizedAccessException ex)

{

  if(ex.Action == SecurityAction.Assert)

  {

    // do somethiung

  }

}

 

 

 

Answer 12

"There was obviously an implied yes in being able to catch multiple types in one block should the block specific a base exception type..."

 

I assumed the OP did not know they could have one catch block of type Exception to handle all exceptions.

 

Thanks for the clarification, Peter.

Answer 13

 

Peter,

 

Good point.

 

Having considered it: Compiler error. ex should be of the highest common base class type (in this case System.Exception I believe). By definition, if we dont care which of the listed exception types we catch then we don't need type specific fields/props.

Answer 14

Peter Ritchie wrote:

What do you expect to happen when you do this: Code Block try { //... } catch( SecurityException, UnathorizedAccessException ex) {   if(ex.Action == SecurityAction.Assert)   {     // do somethiung   } }

Actually, Peter, this example does clear up for me my original question.  I was thinking it would be nice to be able to catch multiple exceptions within one catch statement like that (similar to a switch/case being able to run one case logic block for multiple cases) to save from having to type the same exception handling code for many exceptions.  I understand that the base exception can be used after all derrived... but what I forgot is that the exception variable "ex" is of a certain type, and for particular exceptions would contain information that may not be present for other exception types... and I can see how this would cause a compiler or processing error within the exception block of code if it was catching exceptions for multiple derrived types.

Thanks everybody for your input.

Answer 15

FelixWatts wrote:

Peter,   Good point.   Having considered it: Compiler error. ex should be of the highest common base class type (in this case System.Exception I believe). By definition, if we dont care which of the listed exception types we catch then we don't need type specific fields/props.

So, that syntax would be to solely perform logic independent of the exceptions caught?  i.e. the exception variable would be effectively pointless.

 

 

It's reasonably rare to perform exactly the same processing for more than one exception.  Plus this feature doesn't add any new functionality.  i.e. you could do a similar thing with:

 

Code Block

try

{

}

catch(Exception ex)

{

 if(ex is SecurityExcetion || ex is ArgumentException)

 {

 }

 else

   throw;

}

 

 

 

So I doubt there's enough benefit for a feature of this nature to make it into the language.

Answer 16

 

r3gan, I still think your idea ia a good one. In the example above ex would be of type System.Exception since that is the common ancestor of SecurityException and UnauthorizedAccessException. We can still use ex.Message etc.

 

In a case where you want to catch multiple (non related) exception types in a single block then its unlikely you'll need any type specific stuff (like SecurityException.Action or whatever.)

 

anyhow, it aint gonna happen so.. ho hum. 

Answer 17

Peter,

 

int x, y, z;

 

doesn't add any extra functionality either. And although I agree that it is /reasonably/ rare to handle unrealted exception types the same, nevertheless I have found myself doing it quite frequesntly lately.

 

Anyway, I reckon C# will live on and may even continue to flourish without this feature

 

Answer 18

FelixWatts wrote:

Peter,   int x, y, z;   doesn't add any extra functionality either. And although I agree that it is /reasonably/ rare to handle unrealted exception types the same, nevertheless I have found myself doing it quite frequesntly lately.   Anyway, I reckon C# will live on and may even continue to flourish without this feature

What was in the language from the very beginning is much different than adding functionality.  When the language was created taking into account programmer's habits and porting code was of high importance.  Additions to the language don't have that issue, normally, and involve ensuring compilers aren't destabilized for no good reason and that it doesn't break existing code.  I don't know if the later applies as I'm not on the compiler team.