Alex Rivera | Logout

C# try {} catch {}

Asked 2010-01-21T15:33:59.807
10

hi and thanks for reading. im a newbie in programming and C# and sockets programming. in my code i try and catch problems to provide fault tolarence in my app. the following:

        catch (ArgumentNullException e)
        {
            OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
            OnUpdateNetworkStatusMessage(this, eventArgs);
        }
        catch (EncoderFallbackException e)
        {
            OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
            OnUpdateNetworkStatusMessage(this, eventArgs);
        }
        catch (SocketException e)
        {
            OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
            OnUpdateNetworkStatusMessage(this, eventArgs);
        }
        catch (ArgumentOutOfRangeException e)
        {
            OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
            OnUpdateNetworkStatusMessage(this, eventArgs);
        }
        catch (ObjectDisposedException e)
        {
            OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
            OnUpdateNetworkStatusMessage(this, eventArgs);
        }

i was just wondering if i can replace this repetitive code with one single:

catch (Exception e) { handle here}

would this work?

thanks again.

Edit
Report

2 Answers

16

As a general guideline, don't catch System.Exception. It's a bad idea and a bad code smell indicative of a failure to grasp the purpose of exceptions. I believe it's the result of a dev's belief that exceptions are the error instead of the code that triggered the exception.

I see this failure in production code all the time, and it invariably masks real errors as valid and useful exceptions are caught and swallowed, leaving the application in a bad state. This makes it much trickier to track down the root cause of a failure.

Catching exceptions using the method you've used here is more-or-less the right way to do it. There are a few things you might want to consider improving on, though:

  1. Don't generally treat an ArgumentNullExceptionor ArgumentOutOfRangeException as a runtime network failure (unless it really is). Rather, it should be considered a logic error that causes your program to fail as quickly as possible (so that you can check it out with a debugger as close as possible to the point of failure). This frequently means not catching any ArgumentException at all.

  2. Consider examining the exception hierarchy to find an appropriate base exception that covers the exceptions you're trying to report. E.g., (I haven't looked it up), suppose that three of your exceptions all derived from SocketException. You might save some typing by catching a SocketException instead of the three separate exception. Only do this if you're reporting all socket exceptions, however. (This is basically a more disciplined version of your original attempt to just catch Exception)

  3. Because both lines in every exception handler are identical, you may create a function to do those two lines of work in a single line in the ha

answered 2010-01-21T15:38:30.447
2

As all previous comments suggest, you should catch all the "known" exceptions with exception specific catch block and other unknown, or more appropriately, all "unmatched" exceptions with catch (Exception ex) { ... } or just catch { ... }

However, as specified in your code, you are handling all kind of exceptions in same way. So in this particular case, the output (what you are calling Fault Tolerance) will be the same, but the performance will improve (since the runtime need not compare exception type with given list of types).

Moral of the story : Use single common try-catch in this particular case. But in general, avoid such habit.

answered 2010-01-21T15:55:05.333

Your Answer