いつ try と catch を使用するのが最適ですか? try and catch を使用して質問に答えたときに怒った応答がありました (-1 me もありました...)。Google で検索したところ、この記事とこのスタックオーバーフローの質問が見つかりました。
私はいくつかの例を挙げます:
タイム ゾーン IDのドロップダウン リストがあり、ユーザーが自分のタイム ゾーンを選択すると、データベースが更新されます。他のアプリケーションでは、DB から値を取得し、ユーザーの現在の時刻と日付を再計算しています。DB 内のデータのスペルが間違っているというオプションがあります (DB 内のハードコーディングされた変更またはバグ)。私が使用しているユーザーの日時の変換方法では、try and catch を使用していますが、これは間違っていると言う人もいます。forループを使用してDBから値を確認できましたが、日時を変換するたびにコストがかかります...
次のコードを使用して、XML ファイルが適切にフォーマットされているかどうかを宣言する必要があります。
protected bool IsValidXML(string xmlFile) { try { XmlDocument doc = new XmlDocument(); doc.LoadXml(xmlFile); } catch(XmlException ex) { ///write to logger return false; } return true; }
xml ファイルを確認する他の方法はありません。
アプリケーションの一部をファイルに書き込んでいることがあります。ファイルに書き込むと、さまざまな理由で exeprtion が発生する可能性があります。書き込み中に他のプロセスがこのファイルを使用しているなどです。通常、私はこのコードを使用しています:
using (StreamWriter w = new StreamWriter(fs)) { try { w.Write("** (Line) " + someValue + " **" + Environment.NewLine); w.Flush(); } catch(IOExeption ex){} finally { w.Close(); } }
結論として、try と catch を使用する方法と使用しない方法がいくつかわかりました。私が見た記事の一文には、例外が発生した場合は、それについて知る必要があると書かれていました。、しかし、一般的なアプリケーションを扱うとき、ほとんどの場合、例外が発生することはわかっていますが、ほとんどの場合、なぜそれが発生したのかを本当に知ることができないため、以前にそれをキャッチすることはできません (私が書いた例のように) 、だからいつトライ アンド キャッチを使用するのが最適か
ASP.NET の同じレベルで、ページには次のようにキャッチできるエラー イベントがあります。
this.Error += new EventHandler(Page_Error); //this = instance of System.Web.UI.Page
イベントはtry catch問題と同じですか??