2011年9月5日月曜日

エラーハンドリング勉強会

に参加してきた。復習も兼ねて覚え書きやら思ったことやら。

  • エラーハンドリングモデルの考察(@wraith13さん)
エラーの定義とエラー記録のモデルについて列挙する感じで。
エラーって何かというのは考えだすと難しい話で、分類とか対処法とかきっちり決まっていたら、それって仕様通りの動作なんちゃうの? って話にもなる。
結局どこかで人間の価値判断が入ってくるわけで、そのためにも通知/記録はしっかりと。
エラー時の動作も発生即終了とは限らず、エラー状態のまましばらく走ることも(例外がcatchされるまでスタックをunwindしつつ呼び出し階層を戻っていくとか)あり、その過程でさらなるエラーが起こったりとかも考えうるので、エラー値の持ち方も色々と。


  • エラーハンドリングとアプリケーションの運用(@super_rtiさん)
運用も絡めた話。エラーハンドリングは問題を特定し、可及的速やかに正常な状態にするため。時間の浪費を防ぎ運用コストも低減する。
その観点から、エラーは不正の起こった状況を正確に記録することが重要。何が起こったかだけでなく、何故起きたかも記録すべき。そういう意味では、assertマクロみたいな仕組みも有効なのかなぁ。
またエラーの回収方法も大事。ユーザの作業が必要だったりサイズが大きすぎたりすると、エラー取得そのものが上手くいかない場合もあるので、考えておく必要がある、と。


  • ドキュメントとエラーハンドリング(@cpp_akiraさん)

ドキュメントにはチュートリアルがついてくるけど、そのレベルではエラーハンドリングは省略されていることが多い。ドキュメントまでちゃんと読まないと、想定外のエラーの温床になってしまう。
ソースにあって有用だけどドキュメントに記載のない機能があった場合、勝手に使ってしまうのは良くなくて、作者に確認を取るべき。単なる記載漏れだとしても、それは「ドキュメントのバグ」なので。


  • スタート例外(@ranhaさん)

Exceptional C++の例題(スタックの実装)をHaskellで書いてみて、エラーへの対処戦略を比較。
Optional型や例外送出だとエラーの影響を局在化することが困難なので、スタック操作関数の戻り値型にスタックの状態も持たせることによって、そもそもエラーが発生しないようにして解決。
Haskellがそういう言語だとはいえ、それエラーハンドリングちゃうやん、という話もあるけど、事前に対処に漏れがないようしておくは、どんな場合でも有効なわけで。


  • Actorとエラーハンドリング(@cooldaemonさん

ErlangやScalaでActorモデルを使った場合の、エラーハンドリングのパターンについて。
Erlangではリンクと呼ばれるエラー伝搬の仕組みがあって、1つのActorがエラーで停止すると、リンクしている他のActorも連鎖的に止めることができる。エラーが発生するようなActorは何かが根本的におかしい可能性もあるので、その場でジタバタせずになるべく早く止めて上位で回復動作を行ったほうがいい、というポリシーらしい。
SupervisorのActorはリンクしてても通知されるだけで一緒に死なないが、そういうActorはworker Actorの起動/停止のみで他の処理は」やらない方がいい。
Scalaはまた違う感じだけど、Erlangではこれらはパターンとしてあるだけで、それを強制するシステムはないような感じを受けた。
個人的には並行処理の実装方法の本命はActorモデルだと思っているので、いろいろ参考になった。


  • exception_ptr(@__gfx__さん

C++11で加わった、exception_ptrの話。これまでのC++では、例外オブジェクトはスタック上にできるし、型情報が失われてしまうので自由に持ち運びできなかったけれど、C++11ではcurrent_exception()でexception_ptrを作成すれば一時的に記録できるし、rethrow_exception()に渡せばrethrowできる。
昔、Fiberの中から投げた例外が外に出ていけなくて(スタック切り替えるから当然なんだけど)困ったことがあったけど、これを使えば出来るのかなぁ。そのうち試してみよう。


  • LD_PRELOAD(@egtraさん

勉強会中に作られたとか。テストとして失敗するclose()が欲しいよねという話から、では作ってみましたというLT。LinuxならLD_PRELOADなんだけれど、MacOSなので相当する別のものでやってみたそうで。
エラーハンドリングというか、ユニットテストでは地味に必要な機能なんだよね。このへんで考えてることもあるので、早く形にしてみよう。

といった感じでした。最初にも書いたけどエラーハンドリングは難しくて、みんな試行錯誤している最中かな、という印象。
実装の話に限っても、エラー値は対処漏れがあるし、チェック例外はやってられない、その他の例外も近距離ならいいけれど、throwとcatchが離れるとラベル付きgotoと同じ問題をはらんでしまう、とまだ決定打がない状態だし。

といったところ。

0 件のコメント:

コメントを投稿