{"id":1933,"date":"2009-02-19T17:41:00","date_gmt":"2009-02-19T17:41:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/dotnet\/2009\/02\/19\/why-catchexceptionempty-catch-is-bad\/"},"modified":"2021-10-04T16:06:28","modified_gmt":"2021-10-04T23:06:28","slug":"why-catchexceptionempty-catch-is-bad","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/why-catchexceptionempty-catch-is-bad\/","title":{"rendered":"Why catch(Exception)\/empty catch is bad"},"content":{"rendered":"

 <\/font><\/p>\n

<\/span><\/p>\n

 <\/font><\/p>\n

<\/span><\/p>\n

You’ve seen the advice before—<\/font><\/span>it’s not a good programming practice to catch System.Exception<\/font><\/a>. Because managed exceptions are hierarchical, catching the top of the hierarchy—e.g., catch(Exception)—is an easy way to make sure that you catch all exceptions.  <\/span>But do you really want to catch all exceptions? <\/p>\n

<\/font><\/font><\/span><\/p>\n

<\/p>\n

 <\/font><\/p>\n

<\/span><\/p>\n

Empty catch statements can be just as bad, depending on the MSIL code that your language generates. C# turns an empty catch statement into catch(System.Object) which means you end up catching all exceptions—even non-CLS compliant exceptions. VB is better-behaved, turning an empty catch statement into catch e as System.Exception<\/i> which limits you to catching CLS compliant exceptions.<\/p>\n

<\/font><\/font><\/span><\/p>\n

<\/p>\n

 <\/font><\/p>\n

<\/span><\/p>\n

Instead, you should catch the exact exception types that you expect because these are the types your code is prepared to handle. Obviously, any code that throws an exception is a good candidate for corresponding catch. MSDN documents all exceptions that can be raised from BCL functions. For example, System.IO.StreamReader () can throw ArgumentException or ArgumentNullException. If you use a StreamReader you should catch—and handle—these two exceptions.<\/p>\n

<\/i><\/font><\/font><\/span><\/p>\n

<\/p>\n

 <\/font><\/p>\n

<\/span><\/p>\n

We sometimes see advice that suggests you should catch all exceptions. In <\/font><\/span>Eric Brechner’s Hard Code<\/font><\/a> column he said that letting an application crash and invoke <\/font><\/span>Windows Error Reporting<\/font><\/a> (commonly called “Watson” from the pre-Vista days) was “completely idiotic and irresponsible.” He suggests that instead you catch all exceptions and “try to correct” them. <\/p>\n

<\/font><\/font><\/span><\/p>\n

<\/p>\n

 <\/font><\/p>\n

<\/span><\/p>\n

There’s one small problem with Eric’s advice: the word “try”. When you catch an exception you MUST handle the exceptional condition. Catching an exception is a statement that you can handle the exception and restore the program to a non-exceptional state. Trying to handle an exception isn’t sufficient. Follow the advice of someone older and wiser: “Do, or do not. There is no ‘try’.”<\/p>\n

<\/font><\/font><\/span><\/p>\n

<\/p>\n

 <\/font><\/p>\n

<\/span><\/p>\n

One key problem is that our exception hierarchy is a single mechanism representing multiple exceptional conditions. <\/font><\/span>Krzysztof Cwalina explains this pretty well<\/font><\/a>, breaking exceptional conditions into three sets: usage errors, logical errors and system failures. Usage errors are a condition that should always be fixed by the developer—for example, if an API cannot take null, the developer should ensure that she doesn’t pass in null. Logical errors can’t be detected at development time but should be handled at program runtime by the program itself. For example, a FileNotFoundException should be handled by creating the file or prompting the user for a new filename. System failures, however, cannot be handled by code. System failures indicate that something has gone wrong outside of your program’s scope. Your program can not be expected to correct a system failure. Thus the suggestion that you “try to correct” the error condition cannot reasonably be applied to system failures. <\/p>\n

<\/font><\/font><\/span><\/p>\n

<\/p>\n

 <\/font><\/p>\n

<\/span><\/p>\n

Let’s say your program causes an access violation and you catch the AccessViolationException. What can you do now? Find the pointer which has the bad value and set it to point to the right memory? If you could do that, you wouldn’t have AV’d in the first place. Catching the exception is the wrong thing to do if you can’t correct the error. In the case of a system failure you can’t correct the error.<\/p>\n

<\/font><\/font><\/span><\/p>\n

<\/p>\n

 <\/font><\/p>\n

<\/span><\/p>\n

We’re making a change in Visual Studio 2010’s CLR to make it harder to make this mistake. When an exception could indicate a corrupted process state—what Krzysztof calls a system failure—you’ll have to use a new attribute to indicate your intention explicitly. You can read about the details in the <\/font><\/span>CLR Inside Out column<\/font><\/a> in February’s MSDN Magazine. Even with our Corrupted State Exceptions work, catching all exceptions is not a good idea. If you can’t correct the condition that resulted in an exception being raised you’re always much better off Watsoning up (that is, letting your program exit and invoke Windows Error Reporting.) Watson will report back from the user’s machine so that you can fix the error in your next servicing or release. <\/p>\n

<\/font><\/font><\/span><\/p>\n

<\/p>\n

 <\/font><\/p>\n

<\/span><\/p>\n

<\/p>\n

 <\/font><\/p>\n

<\/span><\/p>\n

<\/p>\n

Andrew Pardoe<\/font><\/p>\n

<\/span><\/p>\n

<\/p>\n

Program Manager, CLR<\/font><\/p>\n

<\/span><\/p>\n

<\/p>\n

<\/font><\/p>\n

<\/span> <\/p>\n","protected":false},"excerpt":{"rendered":"

    You’ve seen the advice before—it’s not a good programming practice to catch System.Exception. Because managed exceptions are hierarchical, catching the top of the hierarchy—e.g., catch(Exception)—is an easy way to make sure that you catch all exceptions.  But do you really want to catch all exceptions?   Empty catch statements can be just as […]<\/p>\n","protected":false},"author":342,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[685],"tags":[],"class_list":["post-1933","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet"],"acf":[],"blog_post_summary":"

    You’ve seen the advice before—it’s not a good programming practice to catch System.Exception. Because managed exceptions are hierarchical, catching the top of the hierarchy—e.g., catch(Exception)—is an easy way to make sure that you catch all exceptions.  But do you really want to catch all exceptions?   Empty catch statements can be just as […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/1933","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/342"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=1933"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/1933\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=1933"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=1933"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=1933"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}