2011-09-20

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

OFF development

http://partake.in/events/9874b92a-4cf0-4a20-a3fe-951239da5612

ご報告が遅くなってしまいましたが、無事 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 さん

http://prezi.com/egmriah4iwfv/presentation/

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

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

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

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

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

Doc and Error Handling

View more presentations from Akira Takahashi

ドキュメントとの整合性のお話。
比較的正確なドキュメントが揃ってるだけその点についてはまだましなんですが、無駄にエラーの返し方にブレがある 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 と若干違うところがあるかも知れませんが日本語訳を起こしましたので↓このあたりもご参照ください。

C++0x の nested_exception について其の壱(仕様) - TrickDiary

他...

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

所感等のリンク

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

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

2011-04-06

エラーハンドリング勉強会を開催します。【発表者募集中】

OFF development

【エラーハンドリング勉強会】
http://partake.in/events/9874b92a-4cf0-4a20-a3fe-951239da5612

エラーハンドリングはどのようにあるべきか？　例外クラスはどのように設計するべきか？　と言った高レイヤーの話題から Windows の SEH や Linux のシグナルまわりの低レイヤー(※1)の話題までエラー処理/例外処理全般で盛り上がりませんか？

...日時や場所は未定のまんまなんですが、発表者の頭数が揃わず話が滞っちゃってます。
なにやら語りたい人、問題提起したい人等々、ご連絡ください。
発表者になって頂ければ当然開催日時も融通します。

あと、会場の提供者も募集中です。

追記

会場は株式会社DeNA様よりご提供頂けることになりました。

2010-10-25

「Boost.勉強会 #3 関西」で「エラーハンドリング」の発表をしてきました。

雑記 OFF C++ development

発表資料等については http://d.hatena.ne.jp/youandi/20101023/p1 とか http://d.hatena.ne.jp/faith_and_brave/20101025/1287979418 あたりを漁ってください。

発表について

前回の反省から今回は早めに動き出していたものの、発表内容で欲をかき過ぎたせいでいろいろ失敗してしまいました。
資料作成に手間取っていたのとどのみち発表時間枠的に無理だと途中で判断し断念しましたが、本当は assert の密度と同じ密度でその続きもやりたかったです。
顔文字はほぼ全てのページに挿入する予定でしたが、これも時間の都合で断念。
寝不足のせいでリスナーとしてもせっかくああいう場で生で聴いてるのにいろいろ台無し。
私が RedBull で買収して発表順を代わって頂いた方も実はその直前まで私の隣で資料を作成していました。

懇親会

お店に向かう列の最先頭グループにいたあんどちんさん( [twitter:@andochin] )はお店を直前にしたところで、別にお店に吸われてしまいました。
我が妹( [twitter:@natiren] )に絡みに行こうとしたら良い場所が無かったのでとりあえず近くのしばやん( [twitter:@shibayan] )のところへ行ったら、しばやんが超饒舌で、会話してるともの凄く喉が渇きました。
しばやんに手持ちのメイドさんが出てくるお店のカードを沢山見せてもらいました。なんであんなに沢山のお店のカードを持っているのか意味が分かりません。
本当の兄弟なの？ってぐらい、しばやんは某変態のお兄さんに雰囲気がなんか似てました。
You&I さん( [twitter:@you_and_i] )が bleis さん( [twitter:@bleis] )を呼ぶ時に「おい！　イケメンッ！　イケメンッ！」って叫んでるのがもの凄く怖かったです。日頃、You&I さんにパシらされてる bleis さんを想像させるような呼び方でした。

はじめてのグリーン車

添乗員がちょろちょろしててウザかった。
なんかおしぼりもらえた。
やっぱり確実にコンセントを利用できるのはいい。
席が広めでその分乗員を減らさなければならないんだしグリーン車分の料金は、まぁ、仕方がないのかなぁと。
でも、一番のグリーン車の良さはその値段の高さから乗客がフィルターされてその分マナーの悪い乗客が居て不愉快な思いする可能性が下がることなんじゃないかなぁと思ったり。