koie blog : エラーハンドリング勉強会にいってきた

http://partake.in/events/9874b92a-4cf0-4a20-a3fe-951239da5612
twitter: #エラーハンドリング勉強会
ustream: http://www.ustream.tv/channel/gunyarakun
togetter: http://togetter.com/li/183534
日時 2011-09-04 14:00〜17:40
場所 DeNA (新宿初台)
参加者: 38人くらい
- なかなか日時場所が確定しなかったので、直前まで開催されることを知らなかった人も多かったようで、キャンセル続出。

10年以上京王線をつかっているが初台で降りたのは初めて。オペラシティがあるのでちょっとハイソな感じ。東口から出たが、地上に上がるときに西寄りにあがってしまい方向がわからず地図をみるはめに。DeNAのビルはすぐわかった。12階からの景色は良好。会社が新宿南口にあったときは6Fだったし都庁がみえるくらいで、見晴らしはよくなかったんだわ。

電源タップをもってきたけど、人が少なかったのもあって余裕。WiMAXの電波強度は中程度。とりあえずチョコレートを喰ってNRG補給しながら開始を待つ。

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

[2011-09-04 14:10]

http://twd.ac/rf5mt1
そもそもエラーとは?
- 前回:正常な状態のすきま
- 今回:なんらかの不整合
エラーハンドリング:不整合を正す
エラー情報モデル
- voidエラーモデル
  - エラーをそもそも検知しない Z80アセンブラとか
- unitエラーモデル
  - 検知するがあつかわない(中断) Icon言語
- singleエラーモデル
  - 86系/Win32API
- stack/nestエラーモデル
  - singleを拡張したもの Java,C#,C++11
- listエラーモデル
  - エラーを検知して必要に応じてその情報をリストで扱う。エラーが発生したまま処理を継続
- treeエラーモデル
  - stack/nestとlistのハイブリッド trickerr.h
人間系エラーハンドリング
- 大本の呼び出し元関数
- 割り込みイベントの発生源
- おそい、失敗、など
- 人間もエラーを返せるべき
- キャンセル・タイムアウト・ヘルプ・バグレポート・など
未検知エラー
- 本来エラーであるべきだが
- すべてバグといえる
- うたがわしきはエラー
- 人間系関数がエラーを返せるべき

[2011-09-04 14:23]

@super_rti / エラーハンドリングとアプリケーションのの運用

[2011-09-04 14:33]

http://prezi.com/egmriah4iwfv/presentation/
シーランド伯爵
rtilabsでぐぐれ
運用までふくめる
エラーハンドリング:アプリの問題をすばやく解決するため
問題の特定にやくだつ情報
エラーとは正常ではない分岐 APIが異常値を返してきたとかのif文
回復処理
- ユーザに判断をあおぐ
- ダイイングメッセージをだして終了
  - 原因の究明
- エラー処理にはいったときの理由(原因)をログにいれるのをわすれないように
ログだけで原因究明できるのが理想
エラーデータの回収
- エラーに気付く→情報調査→原因特定→再現→修正
小規模ならメールでエラー通知、大規模ならgrepか。
youtubはinternal errorをこしたときにエラーコードをエンコードしたのを表示してメールしてね〜、となるのはサーバに残さないのはnなぜだろう。
ネイティブアプリの場合はログはユーザの手元にある
- 初心者・電話だとどうする? → しかけが必要 → ボタン一発で送信できるように・デバッグ版も用意しておく
- コンソール・組み込みはどうなってる? → 修正できないからテストがんばる・そもそもエラーハンドリングを省いて速度を稼いでたり。
クレカ情報などはマスクしてログするとか。

[2011-09-04 14:51]

@cpp_akira / ドキュメントとエラーハンドリング

[2011-09-04 15:03]

http://www.slideshare.net/faithandbrave/doc-and-error-handling
チュートリアル: エラーハンドリングが記載されていないことがおおい。そのままつかうとだめ。
ドキュメントをよんでどんなエラーがでるか。そのプロジェクトで想定しなければいけないものか。
書いてないかもしれない。引数のオブジェクトがエラーをかえすかもしれない。
アンドキュメントなものはバージョンアップで変更・削除される可能性がある。つかわないか、作者に確認する。ドキュメントを送るとか。
ドキュメントに記載されていないエラーがかえってくることがある → ドキュメントのエラー
型付けでエラーハンドリングもれチェック。でも完全じゃない → IDEにたよるか?
アプリケーションコードはすべてドキュメントを書く必要はないが、ライブラリコードはドキュメントは必要。

[2011-09-04 15:13]

ここでいうドキュメントはMSDNのドキュメントだけでなくヘッダファイルのコメントもある。

[2011-09-04 15:15]

@ranha / スタート例外!

[2011-09-04 15:24]

目次
- stackを実装しよう
- Haskellでstack実装
- Cでstack実装
- C++で実装
例外安全
例外中立
Maybeとerrorの2つをつかってhaskellで解説...
- 空スタックのpopをNothingかerrorか
- 会場の半数くらいはHaskellを理解できるらしい...
pushしてpopすると同じものが返ってくるのがスタック性質
emptyにいpushしたらemptyにはならない
空じゃないstack型を用意すればpopがエラーをおこす問題は解決?
addを実装するにはφ・1・2以上という型を用意 → 破綻寸前 → 型に長さを含めてしまえばよい
listにいれるときどうする? → eraseする。
Maybeよりもありえない操作なら静的解析か証明をつける方が好み。
gccのnested functionをつかってpush/popに関数ポインタを渡していMaybeをつかわない書き方。
スタックオーバーフローの対策 → alternate signal stack をつかう。
Exceptional C++をよんでね! がまとめ。

[2011-09-04 16:10]

おやつ

@cooldaemon / Actor とエラーハンドリング〜Erlang 時々 Scala〜

[2011-09-04 16:21]

決済代行業者
- エラーハンドリングはガチガチ
- 国内4秒くらい、海外20秒くらいかかるので、C10K問題にすぐにぶちあたる。
堅牢なシステムをつくりたい→休日に家族サービスができる
並行/分散だからこそ堅牢なシステムがつくれる!
並行/並列の違い: 並列は常に動いている方
- 発表者が「区別できるひと挙手」といってもあまり手があがってなかったようだ。
erlangなら99.9999999%のシステムも夢ではない
Scala: 夢と希望が詰まっている。ゴミがつまってるんじゃない!
リンク:2つのActor間のエラー伝播経路
EXITシグナルは停止するときにブロードキャストされる。停止が伝播する。
障害が発生したActor(ノード)にエラー処理をまかせない。殺してほかのActorに引き継がせる。HAにつながる考えかた。
リンクによる相互監視
- コードがすっきりする
- 回復不能なときだけに使うように
supervisor tree
- actorのリンクをtree状にしたもの
- 上のがシステム(trap_exit=true)になる
actorの孤独死は堅牢ではない→supervisorの下におく
application:supervisor_tree=1:1 にする。トップは1つ。
supervisorは起動・停止だけをする。
workerが起動停止をくりかえしがひどかったらsupervisorを終了。
遠いところとリンクははらないほうがいい。
- ネットワークが切れたら切れたメッセージがくる。(タイマーは調整できる)
- ネットワークが分断されたらどうなるかよくわかんね。
Error Logger
- erlangではcatchされなかったら例外はerror loggerで処理される。
例外
- erlangの例外: error(システムエラー),throw(callerがcatchして対処するかもしれないことを期待),exitの3つ。