2

Is this good practice to wrap every function with try and catch?

I'm building a server in c#, and I'm trying to understand if one of the ways to make it more robust and protected from crashes is to wrap every function in it with try&catch statement.

Is this something reasonable to do??

Eyal
  • 10,777
  • 18
  • 78
  • 130
  • possible duplicate of [Best Practice for Exception Handling in a Windows Forms Application?](http://stackoverflow.com/questions/183589/best-practice-for-exception-handling-in-a-windows-forms-application) – Martin Liversage Mar 03 '12 at 14:09

3 Answers3

8

Is this good practice to wrap every function with try and catch?

Absolutely not. That's a recipe for a disaster - it means you're likely to try to keep going with a request even if something has gone wrong and the state is corrupt.

Typically you should only have catch blocks where you can actually handle the exception and continue successfully; otherwise, you should let the exception bubble up. So you may want to have a catch block in order to retry certain operations, but only specific ones.

You may then have a catch block right at the top level, to stop the server itself from crashing. You haven't told us what sort of server you're building - the framework itself may provide an appropriate catch block like this.

The other reason to catch an exception is to wrap it and rethrow it as a more appropriate one to hide implementation details, and possibly to add more context. This can frankly be a bit of a pain though, and is only useful in certain situations. It really depends on what code is throwing the exception, and how you're expecting to deal with it.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 2
    I think you should add that it may be apporiate to catch an exception to throw your own exception, wrapping the original, for the purpose of adding more information that would be relevent, but not available, to the higher level handler to debugging the problem. – Andy Mar 03 '12 at 14:18
  • @Andy: See the bottom paragraph - I'll edit that to expand it a bit though. – Jon Skeet Mar 03 '12 at 14:52
  • "That's a recipe for a disaster - it means...is corrupt" - Currently if I get an exception in one of the functions(function that response for some client request), I response with an ERROR to the client. It's basic application server i build from zero... the reason I'm currently using a try-catch in every function is to know in which specific function there was an exception... how can I do that with one central try-catch? – Eyal Mar 03 '12 at 18:39
  • @Eyal: "how can I do that with one central try-catch?" -> use an interception framework. An example would be Unity Interception. I believe Castle Windsor has something similar, also. – code4life Mar 05 '12 at 17:17
  • @Eyal: Just log the stack trace. That will show where the exception originated. – Jon Skeet Mar 05 '12 at 17:19
1

Two specific and important notes:

  1. Impersonation - always use try/catch/finally blocks: If you are ever using impersonation, you must always wrap your code in a try/catch/finally block, and put your log-out code in the finally block. The reason is that if an exception is thrown while impersonating, and the exception 'bubbles up', you will still be logged in as the impersonating identity, which is a security risk.

  2. Loops - never use try/catch blocks: try/catch blocks are expensive. If your application hits a roadblock for which the exception should bubble up to the top, that's fine, but never use try/catch within a loop to iterate to the next item. An example might be a loop that performs some calculation and you get a divide by 0 error if the data is bad. Rather than perform the calculation then catch the exception and continue the loop, just check for a 0 and continue to the loop so an exception is never thrown.

Chuck Rostance
  • 6,976
  • 2
  • 25
  • 17
0

I think it's better to wrap group of functions in try and catch different exceptions and handle them. It provides more readable and smaller code with the same functionality

Arсiom Prudnikaŭ
  • 313
  • 1
  • 5
  • 20