usage of try catch

Which is best: Code Snippet 1 or Code Snippet 2 ? And Why?

/* Code Snippet 1
 * 
 * Write try-catch in function definition
 */
 void Main(string[] args)
 {
     AddMe();
 }

 void AddMe()
 {
     try
     { 
         // Do operations...
     }
     catch(Exception e)
     {
     }
 }

/* Code Snippet 2
 * 
 * Write try-catch where we call the function.
 */
 void Main(string[] args)
 {
     try
     {
         AddMe();
     }
     catch (Exception e)
     {
     }
 }

 void AddMe()
 {
    开发者_StackOverflow社区 // Do operations...
 }

The real question to ask is "What is AddMe's contract to the rest of the world?" If AddMe represents the be-all do-all of an interface and correctly handles any exception that encounters in the appropriate way, then sure - let it catch it. If AddMe doesn't or can't know what to do with an exception, then it should throw and defer the handling to the calling code.

It depends, as usual.

In Snippet #1, the error handling is reusable. In Snippet #2, it is not, but that is better in cases where you want to use different error handling in different places.

Other than that, they are identical.

they will operate the same however Most would prefer to catch the logic inside the method if thats where it will be thrown from. Just a best practice though.

There's not best universal way. It depends on how you're going to handle your exceptions.

Do you plan on using a global logger in your main application? The you should have a try/catch block in your main method, and log exceptions there.

You can still try/catch in internal methods if you need to do other stuff with the exceptions, but remember to rethrow them, or else the logger in the main method won't have anything to log.

And remember, to rethrow correctly, use:

throw;

and not:

throw e;

Because the former keeps all the stack trace, while the latter doesn't.

IMHO, allow methods to throw exceptions. Don't attempt to hide when things go wrong. When they do it is up to the client to decide how they'd like to handle the exception. The reasoning for this is because each application may want to do something different with the exception.

TL,DR; Catch exceptions when you can do something about the exception, otherwise let them flow up the call stack until something else will handle them. If the exception cannot be handled by any particular part of your application, your application error event method should handle all the logging for you. Your logging functionality will be your final net for dealing with exceptions.

I've worked with a few shops that require try catch logic on EVERY method, and I learned that the Exception object does a better job watching your call stack than you can.

My other rule of thumb is notify the user of exceptions on user trigger events. So event based or command based captures would be a great place to catch, notify, then re-throw the same exception. (IE throw; NOT throw ex;)

There are already good answers to this question, coming ultimately down to "it depends", but I want to add a thought that I believe greatly influences which method is better for any given situation.

In your code snippet examples, but of your catches are catch (Exception e) {} as opposed to, say, catch (IOException e) or catch (NullReferenceException, or some other narrower exception type. The kind(s) of exception(s) you expect from the code in the try block will make a difference in the way you want to handle it. Especially if you have more than one type to consider, as could be the case if you handle exceptions outside of the subroutine - a large enough upper-level try block could have several different types of exceptions to handle, and start to run the risk of making the code messy.

My general rule of thumb, overall, is that if the exception is a non-critical error (especially if caused by invalid user input), I can handle it in the subroutine and keep the system running. On the other hand, if the exception means the program needs to close, I handle it higher up.