桜、抹茶、白、日記

名古屋市在住のC++使いのcoderの日記だったもの。

エラーハンドリング勉強会 に参加

Event Programming

前日に東京にいたのでついでに参加しました。

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

DeNAさんの会場は受付からしてとても凄かった。そういえば会場近くにスクウェア・エニックスのショップがあってDQグッズとか売っていた。あと開始時間を思いっきり勘違いしていて1時間早く着いてしまっていた。

開会

[twitter:@wraith13]さんのhttp://sites.google.com/site/boostjp/study_meeting/study3での発表が今回の開催の発端となった模様。

[twitter:@wraith13]さん(id:wraith13)


本勉強会でのエラーハンドリングとは何かというのを説明・定義するようなセッション。
エラーとは何か、エラー情報モデルでエラーハンドリング方法について分類。

エラー情報モデルで紹介されていたtreeエラーモデルは以下のtrickerr.hをイメージしたもの。

エラーハンドリングフレームワーク(trickerr.h)
http://tricklib.com/cxx/dagger/

  • 感想等

人間系エラーハンドリングというが面白い考え方だった。人間系をシステムの一部と見なしエラーハンドリングの行き着く先は人間であるというのは確かにそうだなって思いました。

[twitter:@super_rti]さん(id:rti7743)


正しくエラーハンドリングできていれば、うまく対処できる。後はエラーをハンドリングした後に何をすべきかで、ダイイングメッセージ(ログやスタックトレース等)を残す。またログを残すにしても意味のあるものを残すべきである。

  • 感想等

質疑応答でログに個人情報が含まれてしまうのでは？という話が出て、確かにログに何でもかんでも残すのも個人情報保護法やらで気を付けないといけない部分ですね。
自分が実装するときには、エラーログにファイル名、行数、関数名、スレッド、エラーになった条件等を残すようにしていますね。

[twitter:@cpp_akira]さん(id:faith_and_brave)


チュートリアルにエラーハンドリングが記載されていない事が多い。適切なエラーハンドリングするにはしっかりドキュメントを読む必要がある。なのにそもそもドキュメントがなかったりドキュメントに記載漏れがあったりする。それらは適切に是正していく事でそれを利用している人達は幸せになるよね。
また開発言語レベルで、ライブラリの間違った使い方をした場合に検知できるなら、そのように実装しようといったお話。

  • 感想等

自分が質問したかったのは、セッション内容としては、ライブラリのリファレンスについてちゃんとドキュメント化やその維持をしようという話でしたが、プロダクトコードについても同様じゃないでしょうか？的な事だったんですけど、私の説明が下手過ぎましたorz

[twitter:@ranha]さん(id:ranha)


stackの実装をHaskellとC言語で解説。といってもHaskellが時間の8割を使っていたような。締めはC言語に比べるとC++便利だよ、Exceptional C++読もうよって感じだった。

Exceptional C++ Style―40のクイズ形式によるプログラム問題と解法=スタイル編 (C++ in‐Depth Series)

Exceptional C++ Style―40のクイズ形式によるプログラム問題と解法=スタイル編 (C++ in‐Depth Series)

  • 作者: ハーブサッター,浜田光之,Herb Sutter,浜田真理
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2006/09
  • メディア: 単行本
  • 購入: 3人 クリック: 32回
  • この商品を含むブログ (30件) を見る

  • 感想等

Haskellは難しいなぁ。最終的な実装に至るまでの思考プロセスの説明の流れは理解できました。構文的に何をやっているかよく分からなかった。

[twitter:@cooldaemon]さん(id:cooldaemon)

  • Actorとエラーハンドリング：〜Erlang時々Scala〜
  • モチベーション
    • なぜエラハン知識が必要か
    • 堅牢なシステム構築したい
    • 休日に家族サービス出来る
  • 並行や分散を取り入れるとシステムが複雑に
  • ErlangとScala
    • Actorを実装したライブラリや言語はこの二つのみ。
    • Erlang
      • ネットワークサーバーを作るためのDSL
      • 並行と分散が得意
        • 並行：実行状態を保つ
        • 並列：同時に動く状態
      • 高い耐障害性
      • Yaws, Mochiweb, RabbitMQ, CouchDB, Hibari, Riak, Kai, Scalaris, Ejabberd, etc...
    • Scala
      • 夢と希望が詰まっている
      • 並行処理に関するキーワード
        • Thread, Actor, 部分継続, 並列コレクション, 非同期I/O, STM
      • 選択肢が多く、組み合わせも自由
  • Actorモデル
    • 世の中のすべてはActorである
    • 全てのActorは並行に動作する
    • Actorはここにローカルメモリを持ち、Actor間でメモリ共有を行わない
    • Actorはメッセージ受信するためのメアド、メールボックスを持つ
      • メッセージは必ず届く
      • プライオリティなし
    • メッセージの送信は非同期
      • メッセージ順は保証されない
      • メールボックスから任意のメッセージを取り出せる
      • Actorは新たなActorを生成できる
  • リンクによる相互監視
    • EXITシグナル
      • Actorが停止する際に自動的に生成される
      • リンク先の相手に通知される
      • trap_exitフラグ(TRUE:システムプロセス, FALSE:それ以外)
  • リンクの利点
    • 故障箇所をActorに隔離出来る
      • かすり傷で済む
    • リンクはノードを越えて行える
      • 監視ActorとWorker Actorをそれぞれ物理的に離れた別ノードに配置できる
      • 障害が発生した場合に信頼できないActorに処理させない
    • エラー処理は
      • 監視しているActorが処理を引き継ぐ
      • 停止したActorを再起動
      • 引き継ぐActorを別ノードに作成
    • コードがすっきりする
      • 分岐処理を書く必要がない。例外に任せる
      • 回復不能なものの記述が省ける
  • Supervisor Tree
    • 全てのActorはSupervisor配下に設置
      • Supervisorと相互リンク状態にする
      • Actorが孤独死するシステムは堅牢ではない
    • Application:Supervisor Tree = 1:1
      • Supervisorを複数使いたい？
        • RootのSupervisorの下にそれらのSupervisorを複数管理
    • Supervisorの仕事
      • 配下のActorの起動と停止に特化
      • 他の余計な仕事は行わない
    • Supervisor毎の設定
      • 停止したActorのみの再起動(one for one)
      • 停止したActorと同じSupervisor配下のActorを全て再起動(one for all)
      • 一定秒数以内に一定回数以上のWorkerの起動停止を繰り返したらSupervisorを終了
  • Error Logger
    • Erlang OTP
    • Erlangではキャッチされなかった例外はError Loggerで処理される
    • Event Manager
      • 予め任意のEventに幾つかのEvent Handlerを登録
    • デフォルトでttyに出力するEvent Handlerが登録されている
    • Scalar(提案)
      • Event Manager Traitsを作る
      • 上記をextendsした・・・
  • 例外
    • Erlangでは3つの例外がある：error throw exit
      • error
        • システムエラー
        • catch非推奨
      • throw
        • 呼び出し側が対処できないエラー
      • exit
        • Actorの停止
  • 感想等

色々と質問が出たりと盛り上がったセッションだった。

LightningTalks

[twitter:@__gfx__]さん(id:gfx)

「失敗するclose()を作る」というタイトルのLT。
LD_PRELOAD使えばできる！でもMacOSXにはないのでDYLD_ほげほげを利用するといった内容。
でもfclose()はOKだけど、close()では使えなかった。


で、[twitter:@super_rti]さんのsexyhook使えよとお薦めされていた。http://sites.google.com/site/boostjp/study_meeting/study2に動画もあります。

sexyhook
http://code.google.com/p/sexyhook/

[twitter:@egtra]さん


「exception_ptrについて」というタイトルのLT。
C++11で追加されたexception_ptrを利用する事でマルチスレッド処理での例外のハンドリングが便利になるよといった内容。

閉会

19時に東京を出て名古屋に帰ると21時で、翌日は普通にお仕事なので懇親会はパス。