例外処理とエラーパターン
ken
はい、じゃあ、アサイさん、今日もよろしくお願いします。
Yosuke Asai
よろしくお願いします。
ken
はい、ということで、あのブッククラブがね、2冊目始まってますけど、今日は第3章、収録としては2回目かな?
Yosuke Asai
はい、そうです。
ken
今回は例外処理とエラーパターンでしたよね。タイトルが正式なタイトルなんだっけ?
Yosuke Asai
例外バーサス他のエラーハンドリングパターン。
ken
そうですね、例外バーサス他のエラーハンドリングパターンの処理ということで。
はい、今回はトモヒサさんが初ファシリテーション、あの、アサイさん以外の初ファシリテーションということで、
結構、あとタイムゾーンの時間帯もね、今まではヨーロッパが朝のタイミングにやってたけど、ちょっと日本が朝のタイミングにやってみたりとか、結構トライアンドエラーをしてみましたよね。
Yosuke Asai
いや、かなり申し訳なかったですね、これ。あの、今日、日本の方が4人いて、そんな中で朝6時に起こさせるっていう、もっと早く起きてます、皆さんね。
だから、申し訳ないですね。
ken
いやー、これ難しいよね。
はい。
ということで今日もね、はい、今日はあのゲストの方もお呼びしますね。
はい、じゃあゲストの方の紹介を、アサイさんよろしくお願いします。
Yosuke Asai
はい、ということでゲストのしゅんあらはたさんをお呼びしてます。しゅんさんよろしくお願いします。
Shun Arahata
はい、しゅんあらはたです。よろしくお願いします。
Yosuke Asai
はい、しゅんさんは12月くらいに声かけていただいて、確か、あのDDIA終わった後の、何でしたっけあれ、オーロラの話かな?違う。
Shun Arahata
はい、オーロラの話です。
Yosuke Asai
そうですね。の時のリンドク会に参加していただいて、そこから、はい、参加してもらったりとかですね、簡単に自己紹介をじゃあお願いしてもいいでしょうか。
Shun Arahata
はい、えっと、しゅんあらはたです。
今は、えっと、フライミールっていう会社でソフトウェアエンジニアをしています。
フライミールっていう会社は主にデータパイプラインとかを、お客さんからデータを受け取って頑張って作って、
まあ何らかのバリューにつなげるっていう形の会社なんですけど、
今はデータパイプラインとかを書くっていうよりかは、どっちかっていうとサーバー、サービング側で、
主にはNode.jsのバックエンドサーバーとかを書いてたりするんですけど、
最近はKotlinのサーバーとかも書いていて、基本的にはサーバーサイドのエンジニアとして今までやってきています。
ken
データパイプラインを作る仕事とかね、めちゃくちゃ楽しそうですよね。
サービング側ということでしたけどね、今回の輪読会でもそのKotlinのね、ご経験とかもちょい絡めて、
ここら辺ってやっぱり他にKotlin経験者とかもいなかったんで、割と新しい観点を持ち込んでくださったなと思って、
めちゃくちゃ聞いてて楽しかったので、今日はその話をいろいろできたらなと思っています。
Yosuke Asai
なんか本当にしゅんさん入って、すごい引き締まったなっていう感じがして、
さらにバックエンドゴリゴリ書いたことある人が入ってきて、すごい楽しいですね。
ということで、本の感想といってきますか。
ken
そうですね、これ前回思ったんですけど、簡単にリスナーの方向けに、
前やってたアサイサマリーを入れるっていうのやります?
Yosuke Asai
おお、ちょっとだいぶ準備してなかったですけど。
ken
じゃあ僕サマリーでもいいですか。
Yosuke Asai
いいです、お願いします。
ken
そう、多分この本読んでないリスナーの方も多分いっぱいいらっしゃると思います。
Yosuke Asai
いや間違いないですね。
ken
今回、この本はそもそもいろんなトレードオフを話すということで、
今回の章はExceptionとError Pattern、Errorと例外処理ということで、
Javaのコード例を書きながら、例えばこういった例外処理はアンチパターンだよとか、
あとJavaではチェックドとアンチェックとExceptionっていうものがあるけれどもとか、
あとはErrorのヒエラルキ回想構造があるけれども、
これはどういったものをどのようなパターンでちゃんと処理してとか、
処理しないでっていうのを書かれてた本ですよね。
だからむやみにJavaだったらTry CatchとかRubyだったらBegin Rescue Ensureを
ただただ書けばいいだけじゃなくて、書くべきところでちゃんとキャッチしよう。
キャッチしてからもただログに吐き出すだけじゃなくて、
本当に必要なもののデータは何だっけっていう問いを投げかけてくれるようなショーだったかなと思ってますけど、
どうでしょう、法則とお二人あればこんな感じで。
Yosuke Asai
もうそんな感じでいいと思います。
一番最後にパフォーマンスの話とか法則ですけど、
このErrorっていうこのTry and Catchを使うとこうで、これをErrorに書くとこうでみたいな、
そういう話もあって、いろんな観点からTry and Catchとか、
そのErrorを握り潰すみたいなそういう話もあって、いろいろ分かりやすかったですね。
ken
ありましたね。なんかベンチマークフォードがありましたね。
Yosuke Asai
面白かった。
ken
ベンチマーク、そうだ。
ということで、じゃあ今日どんな感じで進めていきます?
じゃあしゅんさんが書いてくれた読書の音というか、ここを深掘って感じにする?
Yosuke Asai
はい、そうしたいです。
型情報を使ったエラーハンドリング
Yosuke Asai
結構しゅんさんがつり返り重てて、
臨読回では全部一個一個いけなかったんで。
そうですね。
ken
聞いてみたいですね。
じゃあまずは初手の質問はざっくりこの章を読んでどう思いましたか?
っていう、新しい観点とかありました?
現場でガリガリサーバサイドを書いてレビューとかしあっている観点でいうと。
Shun Arahata
僕はそのチェック等とアンチェック等、
エクセプションがあるっていうのを完全に忘れてたというか、
多分診察の研修のときにJavaを書いてたくらいでしかJavaの経験、
ピュアなJavaの経験ないんですけど、
そういえばそんなものがあったなっていうのはまず思い出してましたね。
確かに。
結構、エクセプションって考え方は面白いなと思ってて、
ある意味関数のシグネチャーに例外の情報が載ってるみたいな感じだと思うんですけどね。
この関数はどういうエクセプションを投げますみたいなのが。
でも最近、タイプスクリプトのほうのバックエンドのほうが主に書いてた時期が長いんですけど、
タイプスクリプトだと例外を投げることをすると、
それ型情報から分からないからあんまり良くないっていう話をよくしていて、
戻り値の型にエラーの情報を入れると、
キャッチし忘れとかそういうのがなくて、
型のレベルでちゃんとキャッチしなきゃいけないレイヤーをキャッチしてるとか、
そういうのが分かるようにしようっていう流れが最近はタイプスクリプトだとあるんですけど、
それってやりたいこととチェックドエクセプションと気持ちとしては同じ。
チェックドエクセプションもトライキャッチしなかったらコンパイルできないようにするっていうのと、
タイプスクリプトの最近の流行りの例外を返さずに戻り値で頑張るっていうのと、
一緒だなっていうのが初めに結構思って。
ken
なるほど、そこら辺僕ちょっとタイプスクリプトガリガリ書いてるんで分かんないんですけど、
最近のトレンドとかね。
エラーを返すときはどういう型を書くんでしたっけ?
普通にスローしちゃうと、それって戻り値の型に現れないじゃないですか。
このファンクションはスローアブルエラーみたいな感じを書くということですか。
例えば2つ数字を渡して、それの割り算をするっていうファンクションを書くとしますと、
AとBを渡して、中でやってることがシンプルにA割るBを返すみたいな。
10を渡して2を渡したら5が返す。
でもこれ0をBに2つ目の引数に渡したら10割る0になって、
これ計算できないじゃないですか。
例えばこういうシンプルなファンクションを書くときって型ってどう書くんですか。
Shun Arahata
型で多分エラーの情報を渡そうとしたら、
例えばサクセス型とフェリア型ってやつをまず作ってあげて、
それのユニオン型みたいなのをその関数が返しますみたいなふうにやるとかですね。
ken
なるほど。
サクセスってオリジナルのタイプをインターフェース化タイプか何かを定義しといて、
ということですか。それはもうビルドインでネイティブで入ってる方ですか。
Shun Arahata
いや、多分そういうのを何だろう、ビルドインにはないんですけど、
サードパーティーライブラリーでそういうのを書きやすくするためのライブラリーを結構作ってますみたいな人は何人かいたり、
お料でそういう方のそういうのをうまくするためのコードを書いてますみたいな人は多分いる。
ken
オビニオネイティブなライブラリー。
はい、オビニオネイティブなライブラリー。
面白いですね。
Yosuke Asai
呼び出し側が関数を読んだときに、
サクセスかどうか、もしくは失敗かどうかみたいなのをそれぞれ分岐して対応していくみたいな感じになるんですかね。
Shun Arahata
そうですね。
ken
語法っぽいみたいな書き方になるってことですよね。
Shun Arahata
そうですね。
ken
返り値が2つというか、サクセスかフェイラーが返ってくるので、
失敗だったらこう、サクセスだったらこうみたいな書き方をすると。
そうですそうです。
語法とトレンド
Yosuke Asai
ちょっと今日は僕語法全然書いたことなくて、
語法の話も出てきて、結構それもまた勉強になって面白かったんですけど。
なんかこの語法だと、結構情緒だけどエラーハンドリング必ず毎回するみたいな話があったじゃないですか。
ken
そうですね。今日出てきた語法周りの意見ってどんなのがあったっけ。
まず一つ目は、語でよく見かけるif, error, not, equals, nilってのを、
語ではよく書けますよねってのがあって。
これは確かに書くのは面倒だけれども、
これのおかげで本書に書いてるようなトレードオフを考えずに済むみたいな意見もありましたね。
ですね。
Yosuke Asai
この記事とかも面白かったんで書の音に貼っておきましょう。
ken
はい。
すいません、割り込んじゃいました。
いいと思います。そうか。
しゅんさんは語は書いたことあります?
いや、語は全然書いてないです。
でもそのサクセスフェイラーの形でいうと、
そのトレンドというか、
そうやってラップしてマルチバリを返してフェイラーがあるかどうかを
型の恩恵を受けながら書くみたいなスタイルってどうですか。
好き嫌いとか書いてて。
Shun Arahata
僕は業務だとあんまりやろうっていう気にはならないですね。
どっちかっていうと、ある関数がアンディファインドを返すような型にしちゃって、
それをエラーの代わりに使っちゃうってことが多いです。
ken
JavaScriptだと、ぬるの他にまずアンディファインドもあるじゃないですか。
確かに。
例外処理の重要性と言語の違い
ken
これもどっちも混合して使ってたりするコードを読むのめちゃくちゃ辛くないですか。
辛いですよね。
アンディファインドとぬるって、
Yosuke Asai
そもそも言語設計ドーナノ的なのもあると思いますけど。
逆に初心者とかあんまりコードを書いたことない人がコードを読むっていうカーテンだと、
いきなりリザルトが出てくるとまた分かりにくいなっていうのをちょっと思うことがあって、
こういうリザルト関数から返ってくるものが、
エキセプションを出したくないっていうバックグラウンドを知らないと
なかなか読みにくいんじゃないかなっていうのもあるので、
選ぶの難しそうだなと思いましたけど。
ken
そうですよね。
Shun Arahata
業務のチームとかやろうってやると、
結構みんなのこれに関する苦しみとかの経験が多くないと、
多分導入するのは難しいんだろうなと思っていて、
僕も業務ではそういうのはもうやってない。
Yosuke Asai
学者がないとこでライブラリを書いたりしたら、
逆にそれを広めようっていう力は働くんですかね。
そうですね。
ken
でもここら辺どうなんですかね。
結構割と宗教先生寄りのところもあったりしない?
BeamかEmacsかみたいな自分が育ったプログラミング言語に慣れてると、
そのスタイルでやりたいとかわかんないですけど。
Yosuke Asai
そうかもしれないですね。
確かに難しいですね。
ken
これだけで。
で、そのGoの話も何か数年前Goが例えば出て、
みんなやってた頃って書くのめっちゃ大変じゃん。
何で毎回IfErrorNotEqualsに書かなきゃいけないんだって、
みんなやってたと思うんだけど。
全然何ですか、エビデンスのない意見ですけど。
最近だとコード保管のツーリングのほうがすごい充実してきたので、
みんなそんなIfErrorNotEqualsにいるってタイピングはしてないと思うんですよ。
もうGitHubコパイロットとか、
あとAIビルドウィンのエディターとか使ってれば書いてくれるんで、
タブ保管してるだけだと思うんですよね。
なんで書くのがめんどくさいっていう不満がツールによって解消されるから、
みんなメリットのほうを見始めたみたいなのがあるかもしれない。
Yosuke Asai
なるほど、面白いですね。
時代の変化で書き方が変わっていくんですね。
ken
他はどうかな。
何か面白い観点ありますか。
Yosuke Asai
Tomoisaさんの例外処理の方針を決めたほうがいいっていう話に
結構コメントしてる方が多くて、
僕もちょっとコメントしたんですけれども。
ken
これは元々どういう、
Tomoisaさんのコメントでしたっけ。
Yosuke Asai
プロジェクトがあって、
エンジニアが複数かかわると思うんですけど、
そのどのプロジェクトでも例外処理をどう行うかっていうのを
ちゃんと決めておいたほうがいいよねっていう話で、
後に回してしまいがちだけど、
やっぱりエラーハンドリングとか、
障害対応とかするときに、
そうして楽だよねっていう話があって、
これしゅんさんもコメントしたと思うんですけど、
この辺の感想聞いてもいいですか。
Shun Arahata
僕の例外処理のところ。
そうです。
具体的な例を出していたとこですよね。
そうですね。
ある関数の中で、
404エラーになるようなエラーを返しちゃうっていう、
そういうふうな実装していたところがあったりして、
実装しながら、
このエンドポイントのためだけにこの処理変えたから、
404返していいけど、
他のエンドポイントで404じゃないやつを返したいときあるんじゃないかな
みたいなことを思ってたりしながら、
そういう実装をしちゃうんですけど、
実際には、
例えば同じコードなんだけど、
実は同じサーバーがGRPCもサービングしていて、
ってなるとGRPCのエラーコードを返さなきゃいけないから、
関数の中でエラーコードまで決めちゃったエラーを出しちゃうと、
結構困るから、
後で書き直さなきゃいけないみたいなのは結構あって、
エラーを実際どこで出すかっていうのが難しいというか、
僕はどっちかっていうと、
なるべくエラーは出さないほうが好きなんですけど、
エラーというか例外を出さないほうが好きで、
アンディファインドみたいなやつをエラーとして代用できるなら、
とりあえずアンディファインドを返すとかして、
呼び出し側でどうするかを決めて欲しいなっていうふうに思っています。
トライキャッチを変えてしまってもいいんですけど、
トライキャッチ長くなるし、
忘れがちなところはあると思うので、
自分はなるべくエラーを返したくないなって思ってしまいます。
ken
だからこれAPIを設計したり実装したりパブリックに公開する観点から言うと、
多分考えなきゃいけないエラーっていくつかパターンがあると思って、
例えばAPIを使う全員が想定し得るジェネラルなエラー、
例えばAPIを使うのに認証と認可が必要だったら、
ken
オーソライザーとかオーセンティケイト系のエラーは多分どのエンドポイントでも出るし、
例えばバックエンドサーバーが壊れているときに動かない系のステータスコードを出したかったら、
今ビジーなんでバックプレッシャーしてくださいとかっていうのを出すかもしれない。
でも例えばエンドポイントごと、
それこそチェックアウト系決済系のエンドポイントではもっと細かくエラーコードを
エンドポイント側で決めたくなったりとか、
多分その2段階があると思っていて、
それによっても実装の仕方とかライブラリーがどこまで対応しているか次第で、
書き心地も違うだろうし、レビューも違うだろうしっていうことなんで、
本当に書いてる通り例外処理の方針ってのをたぶんかっちり決めないと、
いろんなところに雑にエラーレスポンスを返すコードが散らばっていく、
それをリファクトするのがただひたすら難しくなっていき、
それがパブリックAPIだともうクライアントが依存しているので、
バックコンパティビリティを考慮しながらリファクトするのが超難しくなる、
みたいなのが聞いてと思いましたね、これは難しい話だなと思って。
アサイさんは語を書いてないって言ってたけど、Javaですか?
Yosuke Asai
僕はJava書いてて、あとPythonもちょっと書いてるんですけど、
正直そんなに例外とかを気にしなきゃいけないようなコードを
あんまり書いてることがなくて、そんなにゴリゴリコードを書いてこなかったので、
ken
SR側だもんね。
Yosuke Asai
そうですね、ツールで使うやつとか、
書いてるくらい、Pythonとかも書いてて、
結構書くときはChatGPTとかに聞きながら書いたりしてるんですけど、
この前ChatGPTに出してもらったコードで、
トライキャッチするコードがあって、
それもあんまりよく考えずにそのまま使ってみたんですけど、
よく考えたらそこも別にトライキャッチなんかしなくてもよかったな、
みたいなことを思ったりして、
今回の本を読んでまた自分の理解も向上したんで、
よかったなと思ってますけど。
エラーレスポンスの書き方とトレードオフ
ken
確かにそれもトレードオフですよね。
ちょっとしたスクリプトを書いたりするのに、
30分で終わる仕事をめちゃくちゃエラー処理頑張って2時間になる。
でもそのコードは書き捨てみたいになったら意味ないしね。
Yosuke Asai
はい、そうですね。
ken
それ難しいな。
Yosuke Asai
そうですね、その辺も特にそういうツールとかだと、
あんまり一貫性が強制されないことも多いので、
やっぱりそれを考えなきゃいけないっていう状況だと面倒くさいっていうか、
何ですかね。
いちいち狙い見たくないけど、
でもそれで適当にやるとバグを仕込んでしまう可能性もあるんで、
難しいですよね、この辺。
JavaとKotlinの例外ハンドリングの違い
ken
そうですね、デバッグも難しいですよね。
他の観点としては、
ここでJavaのソースコードの紹介があって、
Javaでは検査例外、非検査例外がありますよね。
英語でチェックドエクセプションとアンチェックドエクセプションがありますっていうのが
本の中で説明があった中で、
そういうのがあるんだなっていう概念を知ったみたいなコメントもあったりとか、
言語によってはこういうチェックドエクセプションだけですよとか、
アンチェックドエクセプションだけですよみたいなコメントもあった中で、
しゅんさんの方からね、コトリンではこういう風にしているよみたいな紹介があったんですけど、
ここら辺、もう一回この場でも簡単に説明してもらえたりしますか。
Shun Arahata
コトリンだとチェックドエクセプションがないっていう話があって、
ken
これ何ででしたっけ。
Shun Arahata
結構まあ、
ken
ふわっと書いてる。
There are many reasons for thisみたいな。
Shun Arahata
結構ふわっと、コードが複雑になるとか、
多分そういう理由だとは僕は理解していますね。
結構トレードオフがあるので、
コトリンは言語レベルでそういうことをやっちゃったんだなっていう形ですかね。
ken
コトリンもJavaのスーパーセットというかね、
というもので書いてるから、
Javaの多分コトリンを言語設計した人がJavaの嫌いなところを、
俺はこうしたいっていう設計多分作ってるでしょうから、
その一つが多分チェックドエクセプションだったんでしょうね。
これ面白いリンクも貼ってくれてますよね。
なんかタイトルがJava's Checked Exception Was a Mistake and Here's What I'd Like to Do About It。
これコトリンに書いた人のブログですか。
誰だろう。
Shun Arahata
いや、コトリンのドキュメントに貼ってあったリンクではあるんですけど、
誰なんだろう書いた人は。
ken
コトリンのリンクにあったらじゃあワンチャンコトリンの言語設計者の可能性ありますね。
Shun Arahata
はい。
ken
ちょっと分かんないですけど。
なるほどね。
なんかやっぱり僕もSREなんであんまり例外、
このAPIとかを普段書いてるわけではないんで、
なんか勉強になったな全体的に。
Yosuke Asai
正直やっぱこの例外と何ですかね、エラーハンドリングみたいなの。
やらなくてもいいでしょってちょっと思ったんですけど。
まあもう全然やっぱ深いですね。話してみると。
やっぱいろんな経験を聞けて、いろんな言語でもやっぱ違ってっていうのがあって。
幅広さと深さがすごいありますね。
例外処理のデバッグの困難さ
ken
そうだよね。でもSREの観点で言ってさ、ちゃんと開発者やってほしいよね。
そうですね、本当に。調査が大変ですから。
なんかありますか、調査大変ネタ。
Yosuke Asai
そうですね。
ken
しゅうさんの方でも、あさひさんの方でもいいですけど。
Yosuke Asai
ちょっと書いたんでしゃべりますけど。
最近あったのは、アウトオブメモリーのエラーが起きていることがあって。
それを調査してて、ちゃんとOMのエラーが出てるログもあれば、
OMなんだけど別のエクセプションが出てしまっているみたいな事例があって。
ken
それどういう状況ですか。同じプロセスというか同じマシンか何かから、
2つ別の?どういう状況?
Yosuke Asai
そうですね。僕も原因全部わかってないんですけど、
いろんなパターンでコードが実行されてて、
とりあえずメモリが足りなくなるんですけど、
あるパターンではちゃんとOMエラーが出てそこで落ちてるんですけど、
別のパターンでは多分変にキャッチされちゃって、
OMのエラーがキャッチされて別のエラーが出てしまうみたいなことがあって、
結果メトリックス上ではOMのエラーがあるのと別のエラーが出てくるんですけど、
実際的にはほぼOMみたいな。でも割合がよくわかんないみたいな感じになってて、
1個直したと思ったら、1個直しても全部直ってないので、
なんかおかしいな、いろいろわからないことが多くて、
すごい混乱するっていうことはあったんで、
やっぱりその辺をしっかりちゃんと落とすべきところで落としてほしいなって思いましたね。
ken
それまず再現方法を探すのが大変そうですね。
どのパターンでOMになって、どのパターンで違うコートパスが走るのかってなると。
Yosuke Asai
そうですね。ちょっとこれは僕もまだ把握できてないんですけど、
再現できてないんで難しいですね。
ken
それはおそらくこの開発した人がこの本を読んで、
きちんと例外設計をすれば省けたはずだということですよね。
Yosuke Asai
そうですね。
ken
とりあえずこの本を買って机の上に投げてきたらいいなって。
Yosuke Asai
やっぱりでもチームが大きくなってくると、
誰がやったのかもわからないっていう感じになってきちゃうんですよね。
だから確かに、もし全員の机に置いておけばいいですかね、こうやって。
ken
お前が読めって言われるかもしれない。
Yosuke Asai
確かに。先に読めって言われますね。
ken
そうそうそうそう。
しゅんさんは何かこう思い出に残っている大変な例外処理デバッグとかありますか?
Shun Arahata
いやー例外処理そんなには思いついてないですね。
ken
大変な例外処理。
ここら辺はやっぱりSREだからよくあるっていうのかもしれない。
Yosuke Asai
しゅんさんもありますか、ちなみに。
ファンクショナルプログラミングの導入
ken
いっぱいありますけど、Neo4jの時、僕もJavaそんなに詳しいわけじゃないんですけど、
Neo4jの時にめちゃくちゃ大変だったのが、
再現方法がわからない障害のデバッグってめちゃくちゃ大変なんですよね。
その時はリーダーのコーディネーションの機能がよくうまく動いてなくて、
基本的には分散システムのデバッグみたいな感じだったし、
Neo4jのJavaのコーディネーションのロジックもすごい秘伝の垂れ込み込みみたいな感じで、
これはどこからやればいいんだみたいな感じだし、
手元で再現環境を作るのも何か数日かかるしみたいな感じで。
いやー大変でしたね。
Yosuke Asai
大変そうなの聞いてるだけで。
ken
そうそうそうそう。
Yosuke Asai
ちなみにRubyとかどうなんですか?
例外処理とか。
一応ディスカッションでもそういう話があったと思うんですけど、
得意な言語でのベストプラクティスみたいな。
ken
そうですね、Rubyは何でしょうね。
例えばパッと見で言うと例外処理のキーワードは、
Javaはtry, catch, finallyですけど、
Rubyの場合はbegin, rescue, ensureみたいな感じで、
何でどこから来てるのかわからないんですけど、
Rubyってそもそも人間の書きやすさ、
開発者の開発者体験というか、
ハッピープログラミングというか、
それをすごい優先してる言語設計なんで、
多分try, catch, finallyって書くより、
begin, rescue, ensureって書いた方が、
自然言語っぽいっていう調子だったのかなという勝手な想像ですから。
Yosuke Asai
いや、直感的で分かりやすいですよ、でも。
ken
rescueのね、
Shun Arahata
救ってくれみたいな感じの。
ken
finallyとかさ、固いよね。
Yosuke Asai
固いっすね。
ken
catchとはみたいな。
一応オブジェクト志向なんで、
exceptionのヘラルキーとかもRubyでもありますし、
書いてる感じで言うとそんなに、
あんまりJavaとか他とかそこまで気にするようなこともないとは思うんだけどね。
Yosuke Asai
ちなみに、
他の言語の話も書いてくださってるんで、
それもちょっと紹介してみますかね。
csharp、トムさんが書いてくださってて、
csharpでは、
コントローラーにexceptionフィルターを付けられるので、
それ内容によって必要なというデスリターンしてみました。
っていうことは、
これはあれですかね、
しゅんさんが言ったresult型とかにちょっと近いんですかね。
ken
これは多分そのvalidationとかを400で返して、
ビルドツールの選択
ken
でもこの提案としてresultとかtryのパターンでもうちょっと返して、
できそうみたいなコメントが書いてありますね。
やっぱりこの本の最後の方かな、
でもトライモナードの話というか、
ファンクショナルにどう書いていくかみたいなところで、
トライモナードの話とかもあって、
これ試したらいいんじゃないみたいな思ってる参加者は結構多いような印象がありますよね。
確かに、トライモナード。
ちなみにしゅんさんの会社では、
ファンクショナルプログラミングっていうのは現場で使われてるったりしますか。
Shun Arahata
いや、全然。
タイプスクリプトは書いていて、
ファンクショナルが好きそうな人は何人か。
この人は本当に。
ken
好きそうな人が勝手に書いてるみたいな。
Shun Arahata
いや、本当にファンクショナルプログラミングをタイプスクリプトで、
もっとちゃんとやるためのライブラリーとかを使って本当は書きたいんだろうなっていうのを。
よくそのライブラリーの話とかされる。
でもまあ、
みんながそのレベルというか、
みんながそこにツラテンを感じているってわけでも、
多分ないので、
あんまりすごいファンクショナルにやろうっていう感じではないですね。
ken
やっぱファンクショナルの世界観ってピュアだからね。
副作用をさ、
すごいこだわってさ、
副作用と副作用のないものをさ、
分けてピュアな世界観を大事にするじゃない。
テストのしやすさとか、
ユニットテストのしやすさとか、
副作用の無さとか、
そこに美しさはやっぱ感じるんですよね。
ハスケルやってたりとか多分、
その数学のバックグラウンドがあったりすると。
で、多分Rxとかもとかかな、
ファンクショナルプログラミングをやってくれるライブラリーとかもいろいろあって、
Java Cookpad時のJavaのとあるソースコードには、
ファンクショナルスタイルが入ってたりとかしたけど。
多分全員、
DDDとかとも一緒で、
ここら辺全員が足並みそらないと結構、
開発速度出ないと思うんですよね。
そうですね。
Yosuke Asai
そう考えると、
なんていうか、
バックエンドって、
SREとかで歴史が長いって言うとあれかもしれないですけど、
そういう宗教戦争みたいなのが大変そうですね。
どうなんだろう。
ken
そうね。
大変というか、
Yosuke Asai
やっぱりみんなの、
なんていうか、
足取りを生きさせるのが難しいのかなってちょっと思います。
ken
啓蒙が難しそうじゃない。
例えばファンクショナルプログラミングでカチッと経験された人は、
それの良さを知ってるから、
それでやろうよって思うわけですよね。
はい。
学習コストあるけど。
で、例えばDDDとかもそうだと思っていて、
学習コストは大変なんだけど、
山を登り切った時の見える世界はめちゃくちゃいいからみんな登ろうよみたいな。
やっぱりそこをちゃんと導入できてる現場は、
やっぱりその学習コストの大変さとか、
採用とかトレーニングとかにもちゃんとインベストして、
投資してやってるから成功する。
だけど、
例えばボトムアップで好きな人がただやってくっていう啓蒙の仕方だと成功しないと思うんですよね。
やっぱりそのCTOとかVP of Engineerとかにいる人が、
ちゃんとその予算とか投資する大事さを持って、
こうちゃんと啓蒙していかないと、
開発スタイルとして文化みたいなもんだからさ。
なるほど。
Yosuke Asai
確かにそういう会社を選ぶとか、
そういう時にあたってはやっぱりそれが共感してるとこに入らないと、
なんていうか辛い思いするかもっていう、
全然話違いますけど。
ken
話違いますけど。
ちょっと思いましたね。
しゅーさんの会社は特徴的なカルチャーってあるんですか?
そういうみんなビーム使ってますとか。
Shun Arahata
特徴的なカルチャーそんなに。
ベイゼルを使ってるとかが特徴的なカルチャーかもしれない。
Yosuke Asai
ベイゼルって何ですか?
ken
何ですか?
Shun Arahata
ベイゼルってビルドツールなんですけど。
ken
あれ?違うか。
Yosuke Asai
バゼルかと思った読み方、あれ?
BASELでしたっけ?
Shun Arahata
バゼルであってます。
ken
バゼルを使ってるっていうのが結構特徴的かもしれないです。
Yosuke Asai
じゃなかったら何を使うんでしたっけ?
Shun Arahata
だからポリゴットっていうか、
そのバゼルはいろんな言語に対応してるビルドツールなんで。
多分普通だったらメイブとか。
分かんないですけど。
メイクファイルでもいいんですけど。
ビルドツールなんですけど、
いろんなに対応しているので、
一応ベイゼルで使って、
TypeScriptとPythonとかJava系の言語とか
ken
全部同じビルドツールでビルドができるみたいな風にはしているんです。
スーパーセットメイクファイルみたいな認識なんですけど、
Shun Arahata
あってますか?
一応それでいいと思います。
チェック済み例外とアンチェック済み例外
Shun Arahata
いいところはCIが、
レポジトリが1個なんですけど、
5分とかぐらいで終わってくれるんですよね、テストとかが。
ken
それはなぜですか?
Shun Arahata
キャッシュをめっちゃ頑張ってやってくれてるんですよ、ベイゼル。
ken
なるほど、なるほど。
Yosuke Asai
いろんな言語を使うときとかにも使いやすいみたいな。
Shun Arahata
そうですね。
結構、どうなんだろう。
プロトとかあると、
プロトの1個の変更がいろんな言語に波及したりすると。
ken
プロトクロパファーのプロトファイルのこと?
はいはい、そうです。
Shun Arahata
結構そういうのいろいろあると思うんですよね。
1個の変更がいろんな言語に波及したりすると。
そういうときに、
全部1個のビルドツールでうまく走ってくれてると、
いろんな言語での影響とかがあっても、
割と1個のCIが落ちてくれるとかで、
多分管理とかやりやすいとかは、
結構そういうメリットはあるのと、
CIが早いっていうのは素晴らしいことですね、開発者としては。
ken
あれは元々Googleから出たツールでしたっけ?
Shun Arahata
元々Googleですね。
ken
あの規模でスケールするようなパフォーマンスが出る
CIツールを作ってるわけだから、
まあ早いよねっていうことなんですかね。
たぶんいろんなオプティマイザーに召喚されていると。
まあ確かにね。
普通にボトムアップでみんな好きなサークルCIとか
GitHubアクションを使っていって、
今後キメランな感じになるよりは、
ちゃんとそこらへんガチッと決めてるっていうのはいいかもしれないですね。
そうですね。
なるほどね。
じゃあ元の本のトピックに戻すと、
じゃあそうですね、
もう一つぐらい、
ブッククラブに出てきた他の方の意見でもいいですけど、
お二人の方でこのトピック観点面白かったなみたいな、
それぞれ一人出して終わる感じにしましょうか。
いいですね。
思いついた人からいきましょうか。
Yosuke Asai
今回新しい参加者のNaoさんって方がいて、
その方がフロントエンドにいじるんですけど、
やっぱりその観点があって、
なんかすごい率直に書いてくださってて、
分からないことは分からないって言ってくださるんで、
かつその分からないところながらも、
自分なりの過去を思い出して書いてくださってて、
すごい自分勉強になるというか、
あとフロントエンドだと、
UIをユーザーに見せなきゃいけないんで、
バックエンドみたいにクラッシュするみたいなのはできないという話があって、
そういう話も全然違う観点で勉強になったし、
良かったなと思いました。
ken
この観点めちゃくちゃ良かったですよね。
僕もフロントエンド分からないっていうのもあるし、
やっぱこう書いてくれる観点が、
なんか自分が普段業務で触れない観点とかだったんで、
なんかすごい勉強になったよね。
すごいメンバーが多様になってきたというか。
Yosuke Asai
本当に。
ken
本当に楽しかったです。
Shun Arahata
セントリーに投げるっていうのもすごい大事だと思います。
確かに。
UIってお客さんの、
お客さんってカスタマーのブラウザー環境で動いてるから、
こっちからロギングしようっていうのが、
バックエンドとかだと会社のインターナルサーバーで言うんですけど、
確かにキャッチしてちゃんとセントリーに投げてあげないと、
お客さんの環境でどういうバグが起こってるかとかが、
トラックできないから、
キャッチしてセントリーに投げるってすごい、
フロントエンジニアが大事だなっていうのを思い出しましたね。
ken
そうですよね。
これ僕も本当にそれを思って、
もう一つすごい良い観点を返ってくれてたのが、
多分フロントエンジニアの観点で言うと、
バックエンドに投げていろんなバリューが返ってきますよね。
JSONとかで、
プロトコルBufferでもいいんですけど、
一つ一つのバリューがヌラブルかどうかをチェックしなきゃいけない。
ヌラブルであればあるほど、
そのチェックがめちゃくちゃ長くなって複雑になっていくってことですよね。
例えば100個フィールドが入ってきたときに、
100個全部ヌラブルだと、
一つ一つにヌラブルかどうかみたいな分岐側を、
100個に対して全部しなきゃいけないんで、
それめちゃくちゃ大変だし、
例えばフルネームとラストネームが別のフィールドで返ってきて、
それぞれヌラブルだったら、
考えなきゃいけないパターンって4パターンだよねみたいな。
ラストネームがあるなしのパターンと、
フルネームがあるなしのパターンだよねとか、
っていうことがあるんで、
フロントエンドエンジニアの目線で例外処理の大変さっていうのがあって、
じゃあそれをどう解決しようかみたいなのは、
コメントで議論だったのかな。
Yosuke Asai
ありましたね。
ken
そうだね。
例外開発するどのフェーズで、
バックエンドチームとフロントエンドが話し合うかみたいなのを、
確かGoogleドックのコメントでちょっと議論になってた気がするけど、
これはやっぱり両者の足並みが揃わないとうまくいかないところなんで、
本当にいい観点だなと思いましたね。
Yosuke Asai
いやー本当に本読んでると思ったら思いつかないですね、こういうの。
フロントエンドの例外処理
ken
やっぱ業務の経験が皆さんあるから、
それを持ち込んでくれてるからさ。
Yosuke Asai
そうですね。
ken
これではね、1人で本を読むことの限界と、
それをどう突破するかみたいな。
だって俺なんか1人で読んだら分かった気になって終わってるもん。
あー俺分かったとか何も分かってないのに。
Yosuke Asai
いやー本当にそれです。
ken
しゅんさんはどうですか?
なんか他の方の観点で面白かった観点とかありますか?
Shun Arahata
そうですよ。
なんか自分が見つけてきたやつなんですけど、
チェックをどういう時に出して、
アンチェックをどういう時にするかっていうのは、
結構ドキュメント、どっからのドキュメントかな?
Oracleのドキュメントに書いてあった、
クライアントがExceptionからリカバリできるなら、
チェックドExceptionにして、
もしそれがダメならば、
アンチェックとExceptionにしろっていうのは結構、
なるほどっていうか、
なんかもうクライアントがリカバリする方法が分かんないんだったら、
もうクラッシュさせちゃっていい気はするんですけど、
まあそういう時はアンチェクトにして、
キャッチしてほしいっていう時は、
キャッチしてどういう風にリカバリする方法がある時は、
キャッチしたらいいけど、
これクラッシュするしかないよねって時は、
別にキャッチすることを強制しなくてもいいっていうのは、
確かになっていう風に思いましたね。
ken
うん、確かにね。
このOracleの記事分かりやすかったですよね。
なんかこれ明日からの業務でも生きてきそうですよね。
なんか自分が例外処理書く時に、
その言語処理系にはなくても、
例外処理の必要性とSREの観点
ken
これJavaで言うとチェックドかなアンチェックドかなみたいな感じで、
これはどうやって処理するのがいいんだろうとか、
レビューの議論もなんか生産的になりそう。
Shun Arahata
僕は昨日役に立ちましたよ。
このキャッチいらなくないですかっていうのを、
力、トライキャッチブロックがあったんですけど、
別にあんまりいらなさそうなトライキャッチブロックで、
これたぶんいらなくないですかっていうのをレビュアーに
強い心で。
ken
すごい、めちゃくちゃいいじゃないですか。
最高じゃん。
自分の背中を押してくれる本があるからね。
はい。
Yosuke Asai
ブッククラブの仲間もいるんで。
ken
そうそうそう。
票は8人もらえるよ。
Yosuke Asai
そうですね。
ken
その観点、てっぺさんも書いてくれてたよね。
これすごいいい観点だなと。
本当に例外処理が必要なケースって実はあまり多くない?
多くなくない?
あまり多くない。
多くない。
Yosuke Asai
多くないかもってことですね。
これはなかなか思いつかないですね。
この本を読んでてそういう結論に達するっていうのはすごいですね。
Shun Arahata
本当は例外処理そんなにいらないよみたいなことは
確かフィロソフィーオブソフトデザインって本のどっかのチャプターで結構書いてあるので。
そうですね。
Yosuke Asai
読んでみたい。
ken
いいですね。
Yosuke Asai
ちなみにけんさんは他に気になるところありますか?
ken
そうですね。実は僕もフロントエンドの観点か
例外処理が必要なケースって実はあまり多くない?を挙げようと思ってたので。
Yosuke Asai
じゃあ僕1個けんさんのところもちょっと触りたいなと思うんですけど。
はい。
ここのレッドイットクラッシュのフェイルオープンのところですね。
これ終わった後に皆さんコメントしてくださってるんですけど
ここはすごい分かりやすかったですね。
特にけんさん説明してもらおうかな。
このところちょっと簡単に。
ken
そうですね。フェイルオープンっていうキーワードを導入したんですよね。
紹介したんですよね。
僕が普段の業務とか最近会社で話題になってて
このショーに絡めそうなトピックがありましたと。
僕はSREの観点で話してるんですけどね。
このショーはプログラマーコードを書く人が
一行一行書いていくときに
一つ一つの例外処理パターンに対して
例外処理をするかどうかっていうボトムアップのアプローチだったんですよね。
システムがきちんと動くことを担保しなきゃいけない
レジリエンシーの観点としては
そのボトムアップのアプローチで限界があると思っています。
なぜならそのボトムアップのアプローチは
全てのHKSに全てのエンジニアがちゃんと導入してくれないと
どこかで必ず漏れがあるからですよ。
だから例えば100人エンジニアデベロッパーがいたときに
50人の人はこの本を読んで
本を読まなくてもこの観点がしっかりあって
例外処理に関してとことん考え抜いて
エラーが出たとしても
ちゃんと処理されるような行動を書いてくれればいいんですけど
残りの50人がそうじゃなかったら
必ずシステムはクラッシュしますと。
なのでSREの観点として
フェイルオープンなシステムとは
ken
みんなこの例外処理頑張ろうっていう啓蒙の仕方は
メイクセンスじゃないと。
じゃあどういうことかというと
フェイルオープンなシステムを作ろうということを言っていて
これは僕が言い始めたわけではもちろんなくて
上の人が言ってたんですけど
それでなるほどと思って紹介してるんですけど
フェイルオープンっていうのは
失敗しても大丈夫なシステムということなんですね。
これの反対が
Let it crashって本でも書いてあったけど
クラッシュしちゃうと。
これのリアルワールドの現実世界の例で言うと
エレベーターとエスカレーターがありますと。
エスカレーターが壊れた場合って
エスカレーターが壊れてもそこに階段はあるんで機能しますよね。
エスカレーターはフェイルオープンなシステムなんですよ。
でもエレベーターっていうのは壊れたら
ワイヤーが切れて
中に入っている人がクラッシュするか
閉じ込められるかっていう
これは全然フェイルオープンなシステムじゃない。
作るならエスカレーターみたいなシステムを作ろうということで
現場の世界に落とし込むと
例えばチャットシステムみたいなのを作っていたときに
チャットの裏側で
例えば外部APIを叩いていたときに
外部APIが壊れたとしますと
そのときにフェイルオープンじゃないシステムというのは
全ての画面がクラッシュしてユーザーが何もできない。
これはダメだ。
じゃあどうするかというと
チャットシステムの例
ken
例えばチャット部分だけがクラッシュしても
障害範囲をなるべく狭めて
別のコンテンツを表示させているところはちゃんと見えるようにしようとか
エラーが起きてもデフォルトとかフォールバックボタンを作って
デフォルトで表示させる
ローディングを表示させるだけじゃなくて
ちゃんとコンテンツがあるものを表示させるような
フェイルオープンなシステムを作ろうみたいな考え方があって
これってレジリエントなシステムを作るために
すごい大事じゃないかなと思って
あえてこのキーワードを紹介したのは
この本は結構ボトムアップの考え方でずっと書かれていたんだけど
トップダウンのアプローチというか
全体像で見たときに
一行一行の例外処理も大事だけど
ユーザーの観点にステップバックしてみたときに
フェイルオープンなシステムを作るのって大事だよねっていう
どっちも必要ですよねということで
このフェイルオープンというキーワードをちょっと話したという感じですね
Yosuke Asai
このエレベーターとエスカレーターの例えが
素晴らしすぎて本当にほっかり使ったですね
ありがとうございます
あと今見ましたけど
このトライアンドキャッチの分散システムではどうかみたいな話も
面白いですね 全然考えてなかったですけど
ken
あえて自分の職種に絡めてこの章を読むならと思って
これ章の一つで確かセクションで
マルチスレッドの環境でのトライキャッチの話もありましたよね
マルチスレッドで話せるなら
これディストリビューティーエンバイアメントも同じことだよねみたいな感じで
ディストリビューティーシステムのトライキャッチはなんだろうなみたいな
議論になったら面白いかなと思って話した感じですね
Yosuke Asai
これまた別のトピックで初書いたいような
またその本を読みたいですね そういう本もありそうですね
ken
これ書いて今話しながら思ったんですけど
この本って確か後半分散システムの話になるよね
そうだそうだ
もしかしたらそこら辺で履歴述するかもね
Yosuke Asai
確かに確かに楽しみだな
ken
読んでないんで僕らへん
そうですね これからですね
今日はどうですね このところかな
まだ2回目なのにすっごい議論が盛り上がってさ
読書ノートとかこれ何文字よっていうかね
確かに
こっち読むほうが時間かかってる そうそうそう
Yosuke Asai
これは本当にまたちゃんと復習して
見にしたいですね ちゃんと
ken
最後にしゅんさんのほうからも
じゃあブッククラブ全体今回のでもいいし
今までの2回分のコメントでもいいですけど
どうですか 今まで参加してもらって
今後へのフィードバックでもいいですし
今後こうしていきたいでもいいし
Shun Arahata
職場のブッククラブに比べると
全然違う開発してる人が多いので
すごい観点が 自分にない観点が結構あって
例えば県産とか財産とかSREとかの観点で
自分の会社SREっていうタイトルの人は
多分いないので
それで確かにSREだとこういうふうに考えるんだ
みたいな感じの驚きとか結構そういうのが
面白いですね
ken
ありがとうございます これは多分まさに
アサヒさんとかもね結構苦労したというか
意識しているところでもあると思うし
多様性ね 会社の多様性もすごいしね
Yosuke Asai
確かに本当に
ken
Metrics作ってる会社の方もいれば
スタートアップの人もいれば
大きい会社もいれば小さい会社もあってみたいな
いやー今度は楽しみですね
はい
はい ということでなんか毎回ね
毎章を読むたびにこう盛り上がりを見せる
ブッククラブを引き続きやっていきましょう
ということで今回の第三章
Exception vs. Other Patterns of Handling Errors in Your Codeは
収録はこれぐらいにしようかな
Yosuke Asai
はい
ken
はい ということでじゃあ
アサヒさん シュウさんお疲れ様でした
Yosuke Asai
お疲れ様でした
Shun Arahata
お疲れ様でした
