2

会社向けの Excel アドインのスイートを開発しています。私はこれまでアドインをやったことがないので、いくつかの複雑なことにはあまり詳しくありません。最初の製品を提供した後、ユーザーは、テスト中に経験/遭遇/気付かなかったエラーに遭遇しました。さらに、Visual Studio のデバッグ環境からそれらを再現するのが困難でした。

プログラムのさまざまな部分からメッセージを受け取る軽量のロギング クラスを作成することになりました。プログラムはそれほど大きくないので、それほど多くの作業はありませんでした。しかし、私が最終的に得たのは、ユーザー環境で起こっていることをログに記録できるように、Try... Catch ブロックでラップされたほぼすべてのコード行でした。

私はそれを適切に実装したと思います.他のクラスやモジュールへの呼び出しをラップするのを避け、代わりにブロックを呼び出しの中に入れようとしました.興味のある情報を記録した後の例外。

私の質問は、本質的に、これは大丈夫ですか？これに取り組むより良い方法はありますか？私は基地外ですか？

クイック編集: 重要なのは、うまくいったことです。そして、バグを突き止めて解決することができました。

4

1 に答える 1

0

いいえ、あなたはベースから外れていません。アドインを作成するときにエラーを処理するには、これが唯一の方法だと思います。このパターンを使用する Outlook アドインを自分で販売しています。ただし、いくつかの注意事項：

  1. ユーザー インターフェイスに直接公開されるか、他のイベントによってトリガーされる最上位のメソッドのみをラップする必要があります。

  2. ロギング ルーチンが例外ツリーを再帰的にトラバースし、InnerExceptions もロギングしていることを確認してください。

  3. 例外を再スローする代わりに、何らかのエラー フォームを表示することを検討してください。

そして、それらのメモへのいくつかのコメント:

  1. あなたはこれを理解していると確信していますが、「コードのほぼすべての行がラップされています(...)」というコメントを見て、これに下線を引きたいと思いました。しかし、はい、例外をログに記録できるように、すべてのコードは最終的に-block になるはずです。catch (System.Exception)私はこれが「危険」であるというグレッグに完全に同意しません。危険なのは、例外を処理しないことです。

  2. これを行う場合、私が正しく理解していれば、「他のクラスやモジュールへの呼び出しをラップすることを避ける」必要はないと思います。github で必要なものをログに記録できる便利な拡張メソッド GetAsString を公開しました。

  3. Outlook では、例外が Outlook 自体に発生した場合、バックグラウンド スレッドで発生した場合、アドインが無効になるか、Outlook がクラッシュすることさえあります。エクセルでもそうじゃない？したがって、私は自分のアプリケーションから例外を出さないように細心の注意を払っています。もちろん、アプリケーションがこの後も実行を継続できることを確認するか、正常なシャットダウンを許可する必要があります。

于 2013-02-08T08:46:45.240 に答える