LOG.debug("nice catch!")
http://connpass.com/event/607/ 2012/06/27 java-ja 『LOG.debug("nice catch!")』#java_ja #javaja
http://togetter.com/li/328035
前回の温泉回に引き続いて、通常回(?)に参加しました。
きっかけ
チキチキ第１回 java-ja 例外とロギング勉強会の募集を開始しました！ goo.gl/siOmh
— やましろさん (@yamashiro) 6月 9, 2012今回の主催者である@yamashiroさんのtweetからたどってまず目に入った以下の内容。
try {今回のテーマに相応しいjavaらしい告知なので即、登録しました。
java-jaで例外とロギングについて勉強します
話していただくのは
俺たちのt-wadaこと和田さんと
PFIの田中英行さん
歩く萌え要素こと西尾泰和さん
歩くモヒカン太一
です
try {
LT.add(ヨシオリ)
LT.add(crexista, 'クライアント側でナイスキャッチ')
LT.add(@shomah4a, 'PyconJPのCfPの宣伝')
} catch (LTTimeoutException lte) {
LOG.debug(ドラ)
}
try {
他にも発表いただくかもです
あとLTやりたい人連絡ください
発表、LTしていただける方は、人数が埋まっていても参加可能です。
} catch (Exception e) {
//OK
}
例のごとく懇親会をそのまま会場でビアバッシュ形式でやりたいと思います。
2000円の予定です
} catch (Exception e) {
//nice catch
}
@t_wadaさんの講演は昨年のTDDBC横浜以来なので、約半年ぶりになります。
前回の温泉回でお世話になった方々の話が聞けるというのも、楽しみでした。
資料
[勉強会][Java]java-ja『LOG.debug("nice catch!")』に参加してきた #java_ja
@shinyaa31さんのブログに詳細な資料があるので、そちらを参照してください。
(@shinyaa31さんありがとうございます)
@shinyaa31さんのブログに詳細な資料があるので、そちらを参照してください。
(@shinyaa31さんありがとうございます)
例外設計における大罪
「契約による設計」は、一番印象に残った内容でした。
実装していく上で呼び出し側と呼ばれた側の関係のそれぞれの役割を考えていないと、それぞれで同じような処理を書いてしまいがちです。
青いレンガについては、ジュンク堂あたりで探して見たいと思います。
Effective Javaを読んでいても活かしきれていないと実感しました。
特に「例外状態の時だけ例外を使用する」については、技術的例外とビジネス例外の振り分けを考えていないとJTAを利用して例外発生時にロールバックが発生するようにしたい・させたくないといったことができなくなります。
そのインターフェースのメソッドにthrow句がついていないのはなぜかということを意識して、実装していかないと非チェック例外でラップして無理やり投げて、呼び出し側でcatchしたり、nice catchして握りつぶしたりしてしまいます。また、インターフェースを作る場合もそれを考えて投げなければいけない例外を投げるようにしなければと感じました。
実装していく上で呼び出し側と呼ばれた側の関係のそれぞれの役割を考えていないと、それぞれで同じような処理を書いてしまいがちです。
青いレンガについては、ジュンク堂あたりで探して見たいと思います。
Effective Javaを読んでいても活かしきれていないと実感しました。
特に「例外状態の時だけ例外を使用する」については、技術的例外とビジネス例外の振り分けを考えていないとJTAを利用して例外発生時にロールバックが発生するようにしたい・させたくないといったことができなくなります。
そのインターフェースのメソッドにthrow句がついていないのはなぜかということを意識して、実装していかないと非チェック例外でラップして無理やり投げて、呼び出し側でcatchしたり、nice catchして握りつぶしたりしてしまいます。また、インターフェースを作る場合もそれを考えて投げなければいけない例外を投げるようにしなければと感じました。
ログ、その時の為に。
ロギングポリシーが曖昧だと必要な場合に限って欲しいログがないということがありがちです。
すでに運用しているシステムの場合、足りないことのほうが多いのも関わらず増やす手段を取るのを忌避されてしまいます。
ログ系のミドルウェアとの連携を考慮して他のインターフェースとの境界を厚めにするというのは、意識していきたいと思います。
SLF4JのMarkerの話があって早速やって使ってみたのですが、同じクラス内の処理でも処理の境界がはっきり見えてくるので、ソースを追わなくても流れをつかむことができます。
出来ればAOPでも使えるようになるとさらにいいと思いました。
SLF4J + logbackは、他のロギングライブラリに比べて使いやすいし、他のロギングライブラリのブリッジも充実しているので、是非新規の場合は利用しましょう。
すでに運用しているシステムの場合、足りないことのほうが多いのも関わらず増やす手段を取るのを忌避されてしまいます。
ログ系のミドルウェアとの連携を考慮して他のインターフェースとの境界を厚めにするというのは、意識していきたいと思います。
SLF4JのMarkerの話があって早速やって使ってみたのですが、同じクラス内の処理でも処理の境界がはっきり見えてくるので、ソースを追わなくても流れをつかむことができます。
出来ればAOPでも使えるようになるとさらにいいと思いました。
SLF4J + logbackは、他のロギングライブラリに比べて使いやすいし、他のロギングライブラリのブリッジも充実しているので、是非新規の場合は利用しましょう。
エラー処理の抽象化
「すごいH本」こと「すごいHaskellたのしく学ぼう！」の翻訳者のかたが基調講演をしてくださいました。
戻り値に処理結果とエラー結果を入れて返すということをやったことありますが、受け取り側で状態ごとで分岐しなければいけないので、めんどくさいですね。
Haskellではモナドというものを使えばできるそうですが、javaにおける例外処理抽象化ライブラリってどんな感じになるんでしょうか。
「すごいH本」に興味が湧いたので読んでみたいと思います。
戻り値に処理結果とエラー結果を入れて返すということをやったことありますが、受け取り側で状態ごとで分岐しなければいけないので、めんどくさいですね。
Haskellではモナドというものを使えばできるそうですが、javaにおける例外処理抽象化ライブラリってどんな感じになるんでしょうか。
「すごいH本」に興味が湧いたので読んでみたいと思います。
最後に
LTでは、クライアント側での例外処理はユーザのこと考えてやろうね。とか運用から見たログについてとかLTじゃもったいない内容が多かったという印象を受けました。
今後DevOpsが増えていくのであれば、地味な印象を受けてしまうログが一番重要なのではないかと思うのでそういった観点での勉強会とかセミナーとか面白そうだと思いました。
fluentdは名前しか知らなかったので、実際にどうやって使っていけばいいのかとか調べてみたいと思います。
主催してくださったjava-jaの皆さん、登壇者の方々、会場を提供して下さったGREE様ありがとうございました。
今後DevOpsが増えていくのであれば、地味な印象を受けてしまうログが一番重要なのではないかと思うのでそういった観点での勉強会とかセミナーとか面白そうだと思いました。
fluentdは名前しか知らなかったので、実際にどうやって使っていけばいいのかとか調べてみたいと思います。
主催してくださったjava-jaの皆さん、登壇者の方々、会場を提供して下さったGREE様ありがとうございました。
GREEさんパネェな！
