Karl....I think the title is bit misleading and suggests you should never use try/catch.

Shouldn't it be "Don't swallow and hide exceptions"?

Totally agree. Can't stand empty catches. I think R# marks them as something bad, or we have something set that does so for us.

If you don't plan on handling an exception, then you shouldn't really be catching it, or you've not written the code correctly (if/else instead?)

Nice little regex to hunt those buggers down:

catch:Wh*\{:Wh*\}

This post was mentioned on Twitter by hoangthienan7: Don't Use Try/Catch: Exception handling has been talked about a lot over the last decade and a half. However, desp... http://bit.ly/8zx301

Same problem in the Ruby world.

<code> rescue nil

It's the equivalent of the empty catch.

Good post!  I would rather have a system hard crash and stop and have to explain that to a customer than have a system take some sort of unforseen plot twist and so something incredibly wacky and have to explain that.

Good article. Developers should properly handle exceptions and know what they are catching.

Good article, although I agree that the title is a little misleading.  There are some cases where exception handling is useful.  However, I completely agree that an empty catch is always a bad idea.

Catching specific exceptions is great and logging additional information before re-throwing the exception is even better.  More information is always useful during debugging.

The Corollary to this rule is "don't throw exceptions for unexceptional behavior". It's even more annoying to have to write essentially swallowing try/catch blocks because the library you call uses exceptions to signal certain not uncommon outcomes.

No no no no no.

Yes, it is bad to just swallow exceptions. No, it is not bad to try to handle exceptions, even unexpected ones. Your suggestion harks back to the bad old days of Windows. I remember too often working in an application like Word and having an exception occur that crashed the application and threw away my work. I would much rather see, let's say "Out of memory" and at least be able to attempt to sabe my work. Your approach means the potential for users to lose data. Do that and you lose customers and fiath in your product.

I like to use try/catch blocks to give exceptions a more friendly description that describes what happened in plain language.   I also make sure to pass in the original exception object as the inner exception thus preserving it for use in debugging.  Also, should you really allow an exception caused by a user failing to fill out a required field bubble up into a global exception handler or should you catch it and display a message to the user indicating what they did wrong?  I'm inclined to think the latter.

My understanding has always been that catching a specific exception (when expected) and dealing with that exception is correct.  To echo Stuart (and others), is the real rant here against catch blocks that swallow indiscriminately?

I have to agree with Kev... the title of your post is "Don't Use Try/Catch", but the point you're actually making is "don't swallow exceptions" or "use exception handling properly".

If your app can recover from an exception, and the exception is truly "exceptional" and not part of the common case, write a handler for it.

If an exception isn't the end of the world, and there is a specific reason that the exception can be safely ignored, then swallow it BUT COMMENT THE CODE ACCORDINGLY.

If your app can't recover from an exception, let it bubble up to a global handler to log it.

I am 100% against abuse of exception handling code, but I'm also 100% against the verbatim statement "don't use try/catch".

As everyone else is saying, its normal and OK to use ...}catch(SomeExceptionIThinkMightHappenAndIKnowHowToDealWith ex){...

A 'rule' isn't needed. All that's needed is to understand that stuff goes horribly wrong if you swallow exceptions.

@Stuart catching and logging is OK as long as you're logging EXTRA info. Don't do this! stackoverflow.com/.../should-i-catch-exceptions-only-to-log-them

Personally I use:

try/catch,

display a friendly custom error page,

and the exception handling application block to log errors in Event Log.

It honestly makes no sense to me to not use try catch in a high quality app.

Nice article, agree with the approach, exception suppressed leaves application unstable and unpredictable

I will usually capture exceptions specifically in service calls that return json.  this way I can

return new {

 error: {

   message: ex.Message,

   debug: IsDebugMode ? ex.ToString() : null

 }

}

Other than service calls, I'll let the global.asax handler do the error handling.  In a service call it can break a lot of the client-side code to have a generic html error page as the result.

[I wrote this at work this morning and was unable to post it... Didn't want to let it go to waste so here it is.]

Karl,

I think that you got a bit of a beating over this post today.  Like the others say this is most likely due to the title of the post.

You are obviously ranting about the code you have found in the compact framework.  Code which is obviously using global or class level variables so I have no idea how it is actually supposed to work.  A LoadImage method that doesn't return a method just seems odd. We'll let that go for now but can easily see how this frustrated you so that you wrote an

incomplete post that focused on your ire.  

If you look at Framework Design Guidelines (Cwalina and Abrams) they dedicate 25 pages to how to work with exceptions. In which they stress don't swallow exceptions.  I take your blog post for what it is.  A rant about something that caused you to loose time and productivity while trying to get your work done.

IMHO, it is possible for the code to use "try { ... } catch (Exception ex) { ... }" effectively.  However this is only the case if the code is API code and you truly only care that a problem occurred and not what the actual problem was. The difference is that there MUST be code in the exception handler.  Most likely this would be wrapping the inner exception and throwing it as an exception specific to the API that makes sense in the context of the call.  So that you can throw a WidgetSaveException instead of a ArithmeticException or FileNotFoundException from a method that is supposed to be saving something to a database.  However, you might want to look at that method more closely as it is probably trying to do too much and could benefit from some refactoring so that you know the exact exceptions your code can throw.

I do disagree with your comment that you should let your global exception handler do most of the work.  It is a better practice to do what you can as close to where the exception occurred as possible.  If it is a fatal error and you want to save data your global handler most likely will not have access to the components needed to save the data.  Plus, this could be more problematic if the save is what caused the exception that ended up in the global exception handler.  As Jim Danby stated you don't want to have customers lose faith in your product.  Any developer needs to work hard to make sure that fatal exceptions are pretty.  I would hope that my customer never see the framework provided exception handler as that means something went horribly horribly wrong.

I would add to that that try-finally block is a nice replacement to what developers originally planned to do with try-catch.

I agree in general, but one place I make er- exceptions - is if I want to implement a TryParse type pattern on a custom type or .NET type that doesn't have one.  (Then, it's still a narrow catch(FormatException){return false;}

Not to beat a dead horse, but yeah, that title stinks. :)

My train of thought around the handling of exceptions typically follows this:

1) Something happens in general, a truly exceptional situation, let it bubble, inform the user, shut it down. (I.e. configuration settings invalid, DB not reachable, etc.)

2) Something happens in a distinct unit of work, nothing is compromised but normal operation has been affected: Log the original exception, raise a unit-of-work specific exception that is displayed to the user as an alert etc. and continue. (I.e. record could not be saved.)

3) Something happens in a distinct unit of work, normal operation hasn't been affected, but something "extra" can't occur, log it, eat it. (I.e. selected item could not be set.)

Eating exceptions isn't bad as long as someone is informed that the system is doing it and why.

The problems with this approach are these :

1/ If I want my app to be able to catch more than one exception : I have a web form with two mandatory field (let say latitude and longitude) , how can I do if I there is an error with the data entered in both field ?

2/ In my app in the saving process, I write an xml file, i insert in a DB,and i call a webservice. If the remote server is down (webexception thrown), How can i delete my line in DB or delete my file ?

Dont try this at work!

I strongly agree with Karl's sentiment: avoid try/catch as much as possible, since when you need try/catch, you'll know. (In contrast, you should use using whenever you can - it's common to see try/catch when there should be a using block instead.)

I also think they commenters talking about unit-of-work have the right idea. Serving a typical web page should normally be considered a single unit-of-work and it's appropriate to use the web framework's built-in mechanisms for handling failures. But if the unit-of-work is, say, placing an order (ie the Place Order button), then you'll want special processing for that.

But it's not normally appropriate for individual functions to catch exceptions. From a design-by-contract point of view, a function must always either return successfully having satisfied its postcondition or terminate with an exception.

Agree, does anyone know of a tool that you can point at a member and which will tell you any exception you might get from that member (and obviously anything it calls).

Exceptions are for exceptional conditions. Exception handling is for exceptional conditions you can do something about.

Karl, I agree with you: For me the base principle is that an application which functions in a normal way should not throw exceptions. I always try to prevent environment issue (readonly files about to be written, mal-formed XML that is about to be read...) to treat the cause before facing the symptom. There are still a few cases that cannot be anticipated upfront (especially when using VS addin API!!!) but globally but they are pretty rare. As a result, when an exception pops, I know that there is certainly a bug in the code.

I wrote about this here:

www.codeproject.com/.../guidelines_exception_cs.aspx

Agreed - a bit of an echo of an article that I wrote a while ago:

thelimberlambda.com/.../on-exceptions

Karl, I have a whole gallery of weird exception handling techniques:

www.aspnetresources.com/.../why_so_averse_to_exceptions.aspx

Hi cool article, but really the title is misleading to it's content! I was like 0.o first time I read the title on DZone and decided to see what it says! Maybe you successfully attracted readers by the title, but still it is misleading and doesn't reflect your point of view.

Good article anyway

Thank you for interesting information. I was searching this information for a long time.

<i>The only time you should swallow exceptions (catch{..} or catch(Exception){...}) is in your global exception handler to avoid truly fundamental issues (and recursive global exception handling). </i>

I would add two exceptions to this.

I'll assume you understand comand query separation. A lot of exception handling could be better written as a query with a command.

ie. if is_float_format (str) then x= float_convert (str) else print "invalid float string" + str

naive but shows the point.

It means that the precondition for float_covert is is_float_format.

However, what about the case for something like inverting a matrix. The predcondition involves calculating the determiner. For a large matrix both take a lot of computation. Far better to have the invert throw an exception if you can't invert the matrix.

The second is  some deeply recursive algorithms, as as an ATN (augmented transition network) for parsing language. Here you may be very deep in the recursion when you find the answer and want to return. It's quicker and neater to return via an exception. Your code is smaller and cleaner, and as a result more likely to be correct. The alternative is return codes and lots of testing of return codes, or implementing your own stack separate from the program stack

Change the title of your post you moron asshole!

@Karl,

It looks like Microsoft employees should be required to use ReSharper :)  It would help them to eliminate catch {}...

I would say: Generally, allow exceptions to occur. Use try ... catch with specific exceptions only, when it is necessary to free some resources or do other specific work, then re-raise exceptions.

Try

Me.ReadArticleAboutNotUsingTryCatch()

Catch titleFailureEx as ArticleIsMisnamedException

Me.SetState( MYSTATES.Unhappy )

Throw

End Try

Which assembly has this code in compact framework?

Thanks Karl

BTW I read your free ebook. Man that's just too good. I liked your approach. Are you considering writing another one. I would like to see write about threading. No pressure :) Its just a wish list :)

Although not directly related to this blog but I am a beginner to unit testing/TDD. Do you have any recommended readings/books in terms of where to start?

Keep up your good work.

" This is particularly true in a web application where you'll only crash 1 thread for 1 user while your site remains accessible."

This isn't really true Carl. If you have any shared state etc you're application is now in an unknown state as a whole.