Simple try/catch not making any use of the exception

Question

I have searched for an answer to my question but not been able to find one. Apologies if the answer is there and I am duplicating!

I keep seeing try/catch code such as.....

try
{
    //Do whatever
}
catch (Exception ex)
{
    MessageBox.Show("Oops, something went wrong!");
}

Which will result in a warning ex is never used.

So my question is... Although ex is never used is there any benefit in the declaration? I was told that maybe it adds detail to the stack trace? Sometimes I see catch(Exception) which stops the warning but what benefits does this bring, if any? If I was to write this and not use the exception in any way I wouldn't declare ex...

try
{
    //Do whatever
}
catch
{
    MessageBox.Show("Oops, something went wrong!");
}

Not a big problem but it would be good to know for sure!

Thanks

Fred

You probably want to write the actual exception to a log so you can debug it later, even if you never show it to the user. — Rup, Aug 15 '12 at 09:47
Yes if you're not interested in what went wrong (up to you) you can do with not declaring the exception — bizl, Aug 15 '12 at 09:50
since you can have several `catch`es, you can thus write `catch(BadFormatException){ /* bad format here */ } catch (Exception ex){ /* unknown error here */ }`. I think that would be a reason to use `catch(Exception)` — default, Aug 15 '12 at 09:51
Both samples are poor form. This is 'demo code', do not use in real applications. — H H, Aug 15 '12 at 09:55

Oded · Accepted Answer · 2016-08-26T19:14:23.777

10

You can use the following pattern, still declaring the specific exception type, without a variable, to ensure Structured Exception Handling (SEH) is still happening:

try
{
    //Do whatever
}
catch (IOException)
{
    MessageBox.Show("Oops, something went wrong in the IO!");
}
catch (Exception)
{
    MessageBox.Show("Oops, something went wrong!");
}

This is not a practice I would normally use, as I would probably log the exception details if not rethrowing it.

edited Aug 26 '16 at 19:14

answered Aug 15 '12 at 09:50

Oded

489,969
99
883
1,009

I had no idea you could catch an exception without having to assign it to a variable (e.g. "IOException ex") until I came across this. Thank you! – Mass Dot Net Aug 26 '16 at 16:53

score 3 · Answer 2 · edited May 23 '17 at 12:32

Suppressing exceptions is usually bad form...let them travel up the stack.

Regarding "adds detail", rethrow the exception using throw to preserve the stack trace otherwise you will lose detail. Again, the alternative is there to not catch it at all. If you don't have any use for the exception (recovery, unwind, etc.), chances are there isn't a good reason to catch it.

See: What is the proper way to re-throw an exception in C#?

See also: "Back to Basics - Exceptions"

score 3 · Answer 3 · answered Aug 15 '12 at 09:49

It's important to note that there's a difference in your two posted code blocks. catch (Exception ex) will only catch CLR-defined exceptions (those that derive from Exception). catch alone will catch anything - including unmanaged exceptions that the CLR hasn't caught or wrapped itself.

If you want to avoid your compiler warning without changing the behaviour of the code, or if you want to avoid the warning whilst still catching a specific exception type, you can use this instead:

catch (Exception)
{
}

The benefit here is that you can be specific: catch (SqlException), for example. If you're not using the variable then declaring give the warning, but the type-specific behaviour is still useful.

Regardless, declaring the exception doesn't add anything to the information (stack trace or otherwise), unless you wrap-and/or-rethrow the exception explicitly. (Incidentally, don't use throw ex to rethrow, because this does lose information: just use throw.)

Habib · Answer 4 · 2012-08-15T09:54:01.723

You can use that ex variable for later usage, including logging, messaging etc.

try
{
    //Do whatever
}
catch (Exception ex)
{
    MessageBox.Show(ex.Message);

}

Suppose you want to log your exception, so that later the developer can take a look at the log and determine what went wrong. In that case ex will hold all the necessary details required for logging. e.g. StackTrace, Message, InnerException if any etc.

For your questions:

Although ex is never used is there any benefit in the declaration?

If you are not going to use, then no benefit in declaring it.

I was told that maybe it adds detail to the stack trace?

I am not sure, but I think it does not. If you define one, then that will contain the Stack Trace of the exception, but it will not add anything to it.

Sometimes I see catch(Exception) which stops the warning but what benefits does this bring, if any?

If you want to re throw the exception using throw keyword, you can use catch(Exception)

Sorry maybe I should have said. I understand why you would have the declaration and the different types of exceoptions you can catch. What I don't know is if there is any benefit to the declaration if you are not going to use it. Seems pointless to me but is there something I am missing? — Fred, Aug 15 '12 at 09:52

score 1 · Answer 5 · edited May 23 '17 at 12:25

1

If you really don't want to do anything with exception, you can also do like so to avoid the compiler warning:

catch (Exception)
{
  // Stick our head in the sand
}

(or just catch)

edited May 23 '17 at 12:25

Community

1
1

answered Aug 15 '12 at 09:49

StuartLC

104,537
17
209
285

score 1 · Answer 6 · answered Aug 15 '12 at 09:51

It's all about the developer and his ability to implement proper logging/debugging in a later term...

this:

catch (Exception ex)
{
    MessageBox.Show("Oops, something went wrong!");
}

could easily be converted to

catch (Exception ex)
{
    Log.Append(ex);
    MessageBox.Show("Oops, something went wrong. Please check the Log file.");
}

sometimes it's merely there for debugging when you run line by line and you can have a break point on the MessageBox.Show line and read the ex variable.

It has it's usefulness, but, at compiled time, if you don't use it, you will get a warning that the variable ex is declared and not used, so, you can track all those and wither Log it, or remove it.

Again, it's all about the programmer choice, and... an unused variable is not that problematic on a ending program.

score 0 · Answer 7 · answered Aug 15 '12 at 09:47

0

No, there's no point in declaring it unless you actually use it.

answered Aug 15 '12 at 09:47

Matthias Meid

12,455
7
45
79

score 0 · Answer 8 · answered Aug 15 '12 at 09:52

The Exception ex which will be the reference to the runtime exception object can give multiple advantages. You yourself as a developer can log it in text file or send a report to yourself.

As of the documentation of MSDN:

If you want to re-throw the exception currently handled by a parameter-less catch clause, use the throw statement without arguments.

http://msdn.microsoft.com/en-us/library/0yd65esw%28v=vs.80%29.aspx

Simple try/catch not making any use of the exception

8 Answers8

Linked