catch(Exception ex) Vs catch (Exception)

catch(Exception ex) Vs catch (Exception)

Post by Y2FzaGRlc2 » Sat, 14 Oct 2006 23:52:03

Nice and simple one for you all...

Is there a time to use Catch(Exception) rather than creating an instance of
the Exception, as in Catch(Exception ex)?

catch(Exception ex) Vs catch (Exception)

Post by Dustin Cam » Sat, 14 Oct 2006 23:56:14

> Nice and simple one for you all...

You don't need to use catch(Exception ex) if you don't want to use an instance
of it. IOW, if you just want to know that a specific exception has occurred
but don't need any of the details, you can omit the ex.

For example:

string text = null;
catch (NullReferenceException)
Console.WriteLine("text is NULL!");

Best Regards,
Dustin Campbell
Developer Express Inc.


catch(Exception ex) Vs catch (Exception)

Post by Chris Fuls » Sun, 15 Oct 2006 00:00:22

It depends if you want to do anything with the exception once you've
caught it, or if you want to re-throw it.
On a similar subject, this article explains the difference between
"throw" and "throw ex":

catch(Exception ex) Vs catch (Exception)

Post by Laurent Bu » Sun, 15 Oct 2006 00:00:50


Both cases do not create an Exception instance. The instance exists, and
was created earlier by calling new ArgumentException( ... ) for example.
Only the "new" keyword really creates objects.

The only difference in the code you show is that, in one case, you get a
reference on the Exception instance (ex), and in the other case you
don't. If you have an instance, and don't use it, you will get a warning
when you compile. That's why you sometimes prefer to use catch (
Exception ), without the "ex".

Such case can occur, for example, when you want to do some clean up when
an error happen:

StreamWriter swr = null;

// do something
catch ( Exception )
// This code is executed if there is an error or not
if ( swr != null )

In the example above, I don't do anything with the exception, thus I use
( Exception ) without ex. If I wanted to do some logging, or maybe wrap
the Exception in another own one, I would do:

catch ( Exception ex )
Trace.WriteLine( ex.Message );
MyOwnException myEx = new MyOwnException( "Error", ex );
throw myEx;

In that case, I'd need the reference to ex, so I must declare it.

Also, note that if you re-throw the exception like in the first example,
you should use "throw;" and not "throw ex;". See

Laurent Bugnion, GalaSoft
Software engineering:
Support children in Calcutta:

catch(Exception ex) Vs catch (Exception)

Post by TWljaGFlbC » Sun, 15 Oct 2006 00:01:02

hmm, only if you want to handle all exceptions (or specific one) and do
nothing with them - nor log or show

Michael Nemtsev :: blog:

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

catch(Exception ex) Vs catch (Exception)

Post by Marc Grave » Sun, 15 Oct 2006 00:03:44

Further to Dustin's comments...

catch(Exception) {...} is a bit pointless, as you could just use catch
{...} - as *every* exception is : Exception. Also, note that you can throw
without capturing the variable by just saying:

catch (SomeTypeOfException) {
Log("**** Happens"); // or whatever...


catch(Exception ex) Vs catch (Exception)

Post by Christof N » Sun, 15 Oct 2006 00:50:18

To be accurate, there is e difference between catch() and catch(Exception).
Though not possible in C#; libraries written in other languages could throw
exceptions that don't derive from Exception. This would be caught with
catch() but not with catch(Exception).
Though no wellbehaving library would throw such 'exception', this behaviour
is explicitly stated in the C# specs.

"Marc Gravell" < XXXX@XXXXX.COM > schrieb im Newsbeitrag

catch(Exception ex) Vs catch (Exception)

Post by Marc Grave » Sun, 15 Oct 2006 01:04:16

I thought they rationalised that around 2.0 with a wrapper type...

But yes, in 1.1 you definitely can (if you are being *** )

oh well...


catch(Exception ex) Vs catch (Exception)

Post by Martin » Sun, 15 Oct 2006 01:21:30

I'm actually curious about throwing non-exception objects - is it any
more efficient than throwing exceptions? After all, with a
non-exception, all of the traceback information, messages, etc. are
gone. In cases where you just want to use the exception as
flow-control or an alternate-return-value-type (yes, I know these are
both Very Bad Things for exceptions) could such an approach be used for
a non-freakishly-expensive exception?

catch(Exception ex) Vs catch (Exception)

Post by Brian Gide » Sun, 15 Oct 2006 01:25:30


In addition to what others have said it's easy to know when you should
choose one over the other. If you get a compiler warning saying ex is
never used then use the other syntax. Likewise, if you actually need
to examine the exception then you'd have to include ex.


catch(Exception ex) Vs catch (Exception)

Post by Bruce Woo » Sun, 15 Oct 2006 01:45:29

First of all, exceptions aren't as terribly expensive as you would
think. See Jon Skeet's article, here:

Second, if you were to throw non-exception objects as a flow control
mechanism, nobody maintaining your code would be expecting that, which
would make your code difficult to understand and therefore difficult to

Sometimes, coming up with a completely different solution to a familiar
problem is a Bad Thing, not because the solution is technically
unsound, but simply because it's unfamiliar and unexpected.

catch(Exception ex) Vs catch (Exception)

Post by Martin » Sun, 15 Oct 2006 02:02:35

I realize that. I just ran into this problem when I misunderstood the
2.0 generic dictionary functionality - I was using the idiom:

string myRes
myRes = dict[someKey];
catch (KeyNotFoundException
myRes = "MyDefaultString";

in C# - and then found out that it had catastrophicly bad performance.
Once I switched over to the TryGet functionality, it behaved much
better. And yet I found myself wishing that I could have just used
exceptions this way. Exceptions provide a nice mechanism for results
that, while not reall "exceptional", don't conform to the primary
return type.

Of course I'd never subject another human being to a bizarre concept of
"alternate return types" as it is a very BadPractice concept. Plus it
mucks up the de *** with lots of "first chance exception" stuff.

I was just curious if it was feasible for my own deepest darkest
hobbyhorse projects. More as a novelty than as a "good idea".

catch(Exception ex) Vs catch (Exception)

Post by Bruce Woo » Sun, 15 Oct 2006 02:59:45

Hey... give it a try. That's how we learn.

Just be sure to post back here with your discoveries. :-)

catch(Exception ex) Vs catch (Exception)

Post by Y2FzaGRlc2 » Sun, 15 Oct 2006 03:02:02

Thanks to all who replied. That clears things up a bit.

catch(Exception ex) Vs catch (Exception)

Post by Martin » Wed, 18 Oct 2006 00:04:06

Never mind - non-exception throws are wrapped with a
RuntimeWrappedException in 2.0 - so that is definitely not the way to
dodge the exception expense.