Should I always wrap my code in try...catch blocks?

Question

Possible Duplicate:
When to use try/catch blocks?
Main method code entirely inside try/catch: Is it bad practice?
When to use Try Catch blocks

Exceptions can occur about anywhere, so this made me think: should I always wrap my code in try..catch blocks?

This is for C#.

(I might be missing something fundamental here, as I'm still a newbie)

EDIT: It appears that this was indeed not a very smart question. The only thing we have learnt at school is to use try...catch to prevent crashes. What we did with the exception was showing a MessageBox to tell the user that 'something went wrong when writing this file'.

@Timst C#. Didn't realise it made a difference, will update my question. — Simon Verbeke, Jan 25 '12 at 17:09
@KenWhite I did a search, but it didn't return that question. — Simon Verbeke, Jan 25 '12 at 17:15
You thoughts on exceptions and them happening just about anywhere is not exactly right. If you exceptions are happening that often in your code, your code is the problem, fix your code. — Security Hound, Jan 25 '12 at 17:26
If you have to use `try..catch` you're probably doing it wrong. — user7116, Jan 25 '12 at 17:30
If you were really meant to do this and it were the panacea that you imagine, don't you think the genius folks at Microsoft would have, I don't know, made it the *default* behavior? (OH WAIT, they did, there's a global exception handler.) — Cody Gray - on strike, Jan 25 '12 at 17:50

score 66 · Accepted Answer · edited Jan 25 '12 at 18:03

Exceptions can occur about anywhere, so this made me think: should I always wrap my code in try..catch blocks?

Good question. Here's a related question:

Axe-wielding maniacs can be just about anywhere, so: should I wear axe-resistant body armor 24 hours a day?

I am fortunate to live in a neighborhood where the number of axe-wielding maniacs is sufficiently low that I don't wear armor when I leave the house. But suppose I did not. Is the right solution to wear the armor all the time or to jail the maniacs?

If your programs throw so many exceptions that you need to be handling those exceptions everywhere, then you have a big problem. The solution to that problem is not to armor up and put exception handling everywhere. The solution to that problem is to eliminate the code that is throwing the exceptions, and if you cannot eliminate it, then isolate it to a tiny region of code that does use exception handling.

[Vexing Exceptions](http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx) - Eric Lippert's article on this topic. — Brian, Jan 25 '12 at 17:45
+1 Great use of an analogy. Makes the explanation much clearer. — Sabuncu, May 08 '14 at 18:15

Paul Sasik · Answer 2 · 2012-01-25T17:19:29.193

Absolutely not. Here's a great CodeProject article on working with exceptions to get you going.

But more to your point in the OP, Exceptions should only be handled where they need to be handled. This means that a well-implemented application will have a few points in the app (depending on scope of course) where a number of specific, Exception-derived exceptions will be handled and even fewer places (one per thread per a number of best practice suggesttions) where the generic Exception will be handled.

When working with exceptions, don't think in terms of a function returning error information. Exceptions greatly alleviate the tedium of percolating an error condition through your call chain.

score 2 · Answer 3 · edited Apr 13 '17 at 12:42

No, you should not wrap all of your code in a try-catch. I answered a similar question here on dba.stackexchange.com - how much overhead an error in RDBMS has.

Generally you should only use exception handling if there's something specific that you want to do with the error message, or if the code that failed produces results that aren't used anywhere else. If the application is user-facing, you obviously don't want them seeing raw exception messages either. In all these cases, you should be logging the failure...no sense in trapping for an exception that you don't plan on handling (empty catch = bad). But otherwise, you will want an exception to be thrown.

For instance, you make a database call and it fails with a SQL Exception. The next part of your code is designed to process that result, so you will want an exception to be thrown and program execution to be halted.

If your code is regularly producing exceptions (and driving logic off of that), you should probably rethink your approach.

Should I always wrap my code in try...catch blocks?

3 Answers3