エラーハンドリング勉強会を開催しました。

OFF development

ご報告が遅くなってしまいましたが、無事 9/4 にエラーハンドリング勉強会を開催することができました。改めて、会場を提供してくださった DeNA 様、発表者、参加者の方々、ありがとうございました。
自分的にはもっとこうニッチな勉強会だろうと思っていたのですが、結局の所、エラーハンドリングって全てのプログラマが無視するわけにはいかないテーマであり幸いな事に予想外に反響は大きかったようです。

「エラーハンドリングモデル考察」 @wraith13

エラーハンドリングモデル考察
View more presentations from wraith13

エラーハンドリングモデルについて考察したいくつかのトピックについて発表させて頂きました。ボリューム不足で大幅に時間を余らせてしまうという失態を犯してしまいすみませんでした。
次にまたエラーハンドリング関連の発表する機会があるとすれば恐らくは tree エラーモデルの実例を交えた解説あたりになるんじゃないかと思います。tree エラーモデルは端からすると仰々しいモデルのように見えるかも知れませんが実のところエラーを投げる側も気軽にバンバンエラーを返すことができ、またエラーリスナーチェーンによってそれを受ける側も非常に効率良くハンドリングできる仕組みを構築できる*1ものだと言うのが私の考えなのですが残念ながら 1 bit たりとも伝わってなさそうなので。(泣
あと、 tree エラーモデルで必須となってくるリスナーなんですが、こいつを外部で差し替えできるようにするのも面白いんじゃないかなぁと思ってたり*2。
これができると例えばあるモジュールを使ってた時にそのモジュール的には問題のないエラーだからと握り潰してたら、実は呼び出し元のプログラムではそのエラーが発生するかどうかは重要なポイントで握り潰されたら困るって場面が発生しても、外部からリスナーを差し替えられるようになっていればどうにかなるし、あと、人間系関数まわりの話でも、素のプログラムでは人間系関数も普通の関数と同じように考えてシステム的視点でよいとされるスタイルでエラーを返しつつもエンドユーザーとの緩衝材となるリスナーを挟めば、システム的にも UI 的にもいい感じにまとめ上げられそうだし、同様にデバッグ時にはデバッグ用リスナーを差し込むとか楽しそう。

あと、最近目にしたエラーハンドリングの話題についての自分なり考察など。

  • エラーハンドリングまわりの開発アプローチ
    • 現実から様々なエラーが引き起こされる。言い換えると、実際に多くの試験をこなしてみないことにはどのような問題がおきるかなんてわからない。机上の設計で初めからしっかりしたエラーハンドリングを構築するのは厳しい。多くの試験(本番含む)をこなしブラッシュアップしていくしかない。
  • 一番詳しいのはエラーを投げるモジュールだからエラーを投げる時は解決方法まで提示するべき？
    • そこまでの要求は無茶なんじゃね？
      • 必ずしもはエラーを投げるモジュールが全てを把握できるわけではない。
      • 現実からどのような問題が沸いてくるかわからない。
      • 現実的な範囲で理想に近いものを提供する努力はしたほうが望ましいのは否定しない。
        • エラーハンドリングそのものと同じく多くの試験(本番含む)をこなしブラッシュアップしていくしかないし、多くの場合はそこまで手間暇かけられずに完成度が低いものになってしまう。

cf. 今回の元ネタとなった Boost.勉強会 #3 関西 での発表資料： PPTX版: http://www.trickpalace.net/paper/error.handling.pptx PDF版:http://www.trickpalace.net/paper/error.handling.pdf slideshare http://www.slideshare.net/wraith13/ss-7987895

「エラーハンドリングとアプリの運用」 @super_rti さん

いつものごとく魅せる発表資料で高いテンションに良いテンポの発表で嫉妬しまくりです。

ログまわりは難しいですよね。デバッグの為に大量にログを吐いたところでそれぞれの問題において重要なパラメータがちょっと欠けてるだけで全く意味を成さなかったり、質問で個人情報云々な話の懸念もありましたけど、バグベアードみたいに大量に吐いてると断片的にではあってもソースコードが漏れると言った状態にもなりますし。

cf. 関連する @super_rtiさんの以前の発表資料 http://prezi.com/1jolcfw5y71g/exception/

# よく見ると TRY CATCH になってるｗ

「ドキュメントとエラーハンドリング」 @cpp_akira さん

Doc and Error Handling

ドキュメントとの整合性のお話。
比較的正確なドキュメントが揃ってるだけその点についてはまだましなんですが、無駄にエラーの返し方にブレがある Win32API みたいなのも勘弁して欲しいところです。一部例外的なものがあるとかじゃなくて全体的にブレまくってるから、ちゃんとエラーハンドリングをやろうとすると各APIごとに逐一どのようにエラーを検知するべきか調べて個別に対応しなきゃならんとか非常に不便極まりないですよね。 ＞ Win32API

あ、あと、発表とは関係は無いのですが、魔導書の２巻をチラ見させて頂きました。もうそろそろ発売されるようです。この文章ちんたら書いてるうちに予約開始されてしまいました。

cf. 関連する @cpp_akira さんが作成している資料 https://sites.google.com/site/faithandbrave/error_handling

「スタート例外」 @ranha さん

この年にもなっていまだに女性に対する免疫が低い自分はことりさん (先週、誕生日だったそうでおめでとうございます。)と度々目が合ってドキドキしてしまい話を聞くの集中できませんでした！＞＜
内容については Stack コンテナの具体的な実装について考察。
しかし、度々、勉強会の類いで Haskell のコードを見せ続けられてるせいでいい加減ちょっとずつ覚えてしまいそう。

「Actor モデルとエラーハンドリング(Erlang 時々 Scala)」 @cooldaemon さん

自分的に一番肝だと思ったのは「分散はシステムが複雑になるけど、稼働率を上げるには必要不可欠。」ってあたりでしょうか。
Actor モデルのメッセージパッシングをベースにコードを書くのって恐らく結構独特なものがあるんじゃないかと思うんですがどうなんでしょう？

「失敗するclose()を作る」 @__gfx__ さん

失敗してくれないとエラーハンドリングのテストができないから、失敗する実装に差し替えちまおうというお話。大事です。

「exception_ptrについて」 @egtra さん

exception_ptr in エラーハンドリング勉強会
View more presentations from egtra

スレッド跨いで例外オブジェクトを扱う時には exception_ptr を使いましょうねというお話。
このまわりについては nested_exception 関連で私も以前に調べて、古い情報を元にしてるので C++11 と若干違うところがあるかも知れませんが日本語訳を起こしましたので↓このあたりもご参照ください。

他...

...低レイヤーまわりの話で期待されていたものの今回は残念ながらお話が聞けなかった @mskwt さんは某筋の情報によると、お体を悪くされているそうで容態が心配です。

所感等のリンク

*1:これらの特徴は厳密には tree エラーモデルではなく主にエラーリスナーチェーンによるところが大ですが。

*2:いま対応することを検討していますが、現時点の trickerr.h は内側のリスナーのほうが絶対的な権限を持っており内側のリスナーに握り潰されたエラーは外部でどうこうできません。