What's the correct time to handle exceptions for methods?

Question

My question is related to exception handling.

If i have for example three methods like this :

Private void Method1()
{
   //My code ...
}

Private void Method2()
{
   //My code ...
}

Private void Method3()
{
   //My code ...
}

And i call the three methods in the page load event like this :

void Page_Load()
{
  if(!Page.IsPostBack)
    {

       Method1();
       Method2();
       Method3();
    }
}

What is the best practice here for exception handling . [Try and Catch] the exception for every method ,i mean in the method implementation.or just wrap the calling of the three methods with a single [Try-Catch] in the page load...

That depends on what you want to do in the exception handler. If you want to let the user know what went wrong, you'll need separate exception handlers for each. If you just want a generalised "Something went wrong and I'm not going to tell you what it was", one is enough. — Mr Lister, Mar 25 '12 at 20:06
You should catch and log exceptions as soon possible. What you're doing then depends on the context. You might want to call `Method2` even when `Method1` has raised an exception. You might want to provide a custom error-page and catch all passed exceptions in [Application_Error](http://msdn.microsoft.com/en-us/library/aa479319.aspx#customerrors_topic6). — Tim Schmelter, Mar 25 '12 at 20:11

score 3 · Accepted Answer · answered Mar 25 '12 at 20:10

You should only try{}catch{} if you know how to recover from an exception.

In all cases, having a global/top try{}catch{}/error handler in order to log the errors is good practice.

In general, if you don't know how to handle an exception, don't catch it. Don't swallow such exceptions either - try to close the application/thread as gracefully as possible.

score 1 · Answer 2 · edited May 23 '17 at 11:52

1

Take a look at my answer here. This is a rather broad subject, but I've summarized a few things to consider. It's not by all means the end-all answer for this, but I've summarized 5 points that might help your decision.

edited May 23 '17 at 11:52

Community

1
1

answered Mar 25 '12 at 20:10

Bryan Crosby

6,486
3
36
55

Rhapsody · Answer 3 · 2015-10-28T17:58:43.503

-1

In my opinion you should put try catch in all methods. Like that you'll be able to track errors more easily.

But as far as I know, it is best practice to use try catch only when dealing with external sources. (i.e. file IO, database communication etc) This because try catch brings some overhead.

(when voting down, please tell me why. This helps me, but also the person who asked the question.)

Edit: See my last comment. As others have pointed out, putting a try/catch block everywhere does not make sense at all!

edited Oct 28 '15 at 17:58

answered Mar 25 '12 at 20:08

Rhapsody

6,017
2
31
49

Yes, only try-catch the things you can't catch with code. For instance, if you're afraid you may get a division by zero, check the values of the operands first and don't slap a try-catch block around it. – Mr Lister Mar 25 '12 at 20:10
1

Try catch everywhere? What about when there is an `OutOfMemoryExcpetion`? Catch that too? – Oded Mar 25 '12 at 20:11
It can be beneficial to `try`/`catch` in most methods. As the application becomes increasingly complex it become more and more difficult to control the bubbling-up of exceptions. So in this respect @Rhapsody's post is not warranted a down vote (+1). What is meant to be illustrated by the example of the `OutOfMemoryException`? [This answer says it all with regard to OOM exceptions.](http://stackoverflow.com/a/2117175/626442) – MoonKnight Mar 25 '12 at 20:19
2

@Killercam - The point is that there is absolutely no point in putting catch blocks around every piece of executable code. The OOME example is about the futility of trying to catch everything. Pokemon exception handling is **not** good practice. – Oded Mar 25 '12 at 20:26
OK. Thanks. I personally don't do this but I can't really see a major issue with doing so if it simplifys exception handling. I will take what you have said on board and read a bit more. Thanks again. – MoonKnight Mar 26 '12 at 08:04
Just read my answer from a couple of years ago. I totally changed my mind about this. When dealing with external sources, try/catch might be a good option, since you do not have any control about what the external source returns. But further I'd recommend a TDD approach where the code is covered by tests as much as possible. – Rhapsody Oct 28 '15 at 17:54

What's the correct time to handle exceptions for methods?

3 Answers3