CODEWITHSUNDEEP
.netexception
CleanCoder
CleanCoder

Reputation: 887

Difference between catch(Exception), catch() and just catch

I want to know if I can safely write catch() only to catch all System.Exception types. Or do I've to stick to catch(Exception) to accomplish this. I know for other exception types (e.g. InvalidCastException), I have to specify the type as catch(InvalidCastException). In other words, I'm asking if the following code samples are the same.

This ...

try
{
    //do something
}
catch(Exception)
{
    //handle exception
}

this ...

try
{
    //do something
}
catch() //Causes compile time error "A class type expected"
{
    //handle exception
}

and this ... 

try
{
    //do something
}
catch
{
    //handle exception
}

update: There was an error in my question. catch() is not allowed in c#.

Upvotes: 22

Views: 7150

Answers (5)

Yogesh
Yogesh

Reputation: 59

catch(Exception ex) can handle all exceptions which are derived from System.Exception class, however if the exception thrown is not derived from System.Exception then it will not be handled by catch(Exception ex).

Prior to .NET 3.0 exceptions thrown by unsafe code (i.e. code not targeting CLR) were handled by catch{}. After .NET Framework 3.0 all types of exception can be handled by System.Exception class. catch{} is now obsolete .

Upvotes: 5

supercat
supercat

Reputation: 81159

If the fact that an exception occurs implies that you need to run a piece of code, but you wouldn't do anything with the exception except rethrow it if you caught it, the preferred approach is probably not to catch the exception but instead do something like:

  bool ok=false;
  try
  {
    ... do stuff -- see note below about 'return'
    ok = true;
  }
  finally
  {
    if (!ok)
    {
      ... cleanup code here
    }
  }

The one weakness with this pattern is that one must manually add an ok = true; before any return statement that occurs within the try block (and ensure that there's no way an exception (other than perhaps ThreadAbortException) can occur between the ok = true; and the return). Otherwise, if one isn't going to do anything with an exception, one shouldn't catch it.

Upvotes: -1

ken2k
ken2k

Reputation: 48985

In a perfect world, you shouldn't use catch(Exception) nor catch (alone) at all, because you should never catch the generic Exception exception. You always should catch more specific exceptions (for instance InvalidOperationException...etc.).

In a real world, both catch(Exception) and catch (alone) are equivalent. I recommend using catch(Exception ex) when you plan to reuse the exception variable only, and catch (alone) in other cases. Just a matter of style for the second use case, but if personally find it more simple.

What's really important (even if it's out of the scope of your question) is that you never write the following piece of code:

try
{
}
catch (SpecificException ex)
{
    throw ex;
}

This would reset the stack trace to the point of the throw. In the other hand:

try
{
}
catch (SpecificException)
{
    throw;
}

maintain the original stack trace.

Upvotes: 20

Frédéric Hamidi
Frédéric Hamidi

Reputation: 262949

Both constructs (catch () being a syntax error, as sh4nx0r rightfully pointed out) behave the same in C#. The fact that both are allowed is probably something the language inherited from C++ syntax.

Others languages, including C++/CLI, can throw objects that do not derive from System.Exception. In these languages, catch will handle those non-CLS exceptions, but catch (Exception) won't.

Upvotes: 9

Raphaël VO
Raphaël VO

Reputation: 2640

Take a look at this link: http://msdn.microsoft.com/en-gb/library/0yd65esw.aspx

I think it will be ok, have or not but you can let argument in statement catch to get exactly the exception that you want and handle them rightly.

Upvotes: 1

Related Questions