Why catch(Exception)/empty catch is bad

Why catch(Exception)/empty catch is bad

  • Comments 69

  

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 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 which limits you to catching CLS compliant exceptions.

 

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.

 

We sometimes see advice that suggests you should catch all exceptions. In Eric Brechner’s Hard Code column he said that letting an application crash and invoke Windows Error Reporting (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.

 

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’.”

 

One key problem is that our exception hierarchy is a single mechanism representing multiple exceptional conditions. Krzysztof Cwalina explains this pretty well, 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.

 

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.

 

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 CLR Inside Out column 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.

 

 

Andrew Pardoe

Program Manager, CLR

 

Leave a Comment
  • Please add 1 and 1 and type the answer here:
  • Post
  • 誰か満足させてくれる人いませんか?めんどくさいこと抜きでしよっ♪ gu-gu-m@docomo.ne.jp とりあえずメールして☆

  • 全国各地の女性会員様の性欲を満たし、割り切ったアルバイト感覚で稼げる逆円バイト。報酬は平均で1回5〜10万円となっております。興味のある方は当サイト新規無料エントリーからお早めにどうぞ

  • 家出をして不安な少女の書込みが当、家出掲示板では増えています。泊まらせてあげたり、一日遊んであげるだけで彼女たちはあなたを神と呼び、精一杯のお礼をしてくれるはずです

  • あなたのゲーマー度を無料ゲーム感覚で測定します。15個の質問に答えるだけの簡単測定で一度遊んでみませんか?ゲームが得意な人もそうでない人もぜひどうぞ。

  • Hな女性たちは素人ホストを自宅やホテルに呼び、ひとときの癒しを求めていらっしゃいます。当サイトでは男性ホスト様の人員が不足しており、一日3〜4人の女性の相手をするホストもおられます。興味を持たれた方は当サイトにぜひお越しください

  • 実は出会い系には…関係者用入り口があるのを知っていますか?広告主やスポンサー用に用意されたIDではサクラや業者が立ち入ることが出来ないようになっているのです。当サイトでは極秘に入手した関係者用URLが公開されています

  • 男性はお金、女性は快楽を得る逆援助に興味はありませんか?お金を払っても性的欲求を満たしたいセレブ達との割り切り1日のお付き合いで当サイトでは大金を得ることができます。無料登録なのでアルバイト感覚でOK、詳しくはTOPページでどうぞ。

  • 自分のほむぺ初公開でぇす。やっと完成したのでみんなに見てもらいたくて★カキコしました。意見ある方めぇるまってまぁす。 ggg.nj@docomo.ne.jp

  • 夏休みで気軽に家出する女子○生が急増しています。しかし家出したはいいものの泊る所やお金が無い彼女たちは、掲示板などで泊めてくれる男性を探す子も多いようです。当掲示板にも夏休みに入ってから通常の3倍以上のメッセージが寄せられています

  • 今夏も新たな出会いを経験してみませんか?当サイトは円交の逆、つまり女性が男性を円助する『逆円交際』を提供します。未経験の方でも気軽に遊べる大人のマッチングシステムです。年齢上限・容姿・経験一切問いません。男性の方は無料で登録して頂けます。貴方も新たな出会いを経験してみませんか

  • 素人ホストでは、男性のテクニック次第で女性会員様から高額な謝礼がもらえます。欲求不満な人妻や、男性と出会いが無い女性達が当サイトで男性を求めていらっしゃいます。興味のある方はTOPページからどうぞ

  • さゆのプロフィールが完成しましたぁ。記念すべき初プロフをネットに公開してみました。ドキドキしてるので優しい感想メールしてくれたら心和むかもでぇす po.tomoe.oq@docomo.ne.jp

  • 当サイトではセレブ熟女の性欲を満たしてくれる男性に高額謝礼をお支払いし、デートや一晩のSEX、月契約など選べる逆援出会いの場を作っております。アルバイト感覚でもお待ちしておりますので当サイトで無料登録をどうぞ

  • カワイイ子ほど家出してあそんでみたくなるようです。家出掲示板でそのような子と出会ってみませんか?彼女たちは夕食をおごってあげるだけでお礼にHなご奉仕をしてくれちゃったりします

  • 出会ぃも今は逆援助!オンナがオトコを買う時代になりました。当サイトでは逆援希望のセレブ女性が男性を自由に選べるシステムを採用しています。経済的に成功を収めた女性ほど金銭面は豊かですが愛に飢えているのです。興味のある方はどうぞ

Page 4 of 5 (69 items) 12345