00:01
Yoshiori Shoji
というわけで、これはyoshioriとドラフト コードが、タメ口でプログラミング
について、ぐだぐだ話すポッドキャスト です。僕がyoshioriです。よろしくお願いします。
draftcode
ドラフトコードです。これ何回目?
Yoshiori Shoji
三回目。
三回目。なんと三回目だ。
三ヶ月ぐらい空いてるんだね、もう ディフェンデーションゲームから。
前回8月って書いてあるね。
draftcode
なかなかだね。
Yoshiori Shoji
今日はエラーハンドリング。
draftcode
そう。みんな大好き。
Yoshiori Shoji
みんな大好き。
draftcode
プログラマーの人生の80%はデバッキング だとしたら、残りの20%はエラー処理
だからね。
Yoshiori Shoji
そうね。大体本番とかで出たエラー の原因を調べてみたいなのがメイン
の仕事だったりするよね。正直に話を まずしておくと、その前に2個ぐらい
あって、1個がまだ積が残っている ので放送に積が乗るかもしれません。
ごめんなさいという感じですね。 ゲホゲホってたまに乗るかも。
もう1個。前回2回オブジェクト思考 とかディフェンデーションインジェクション
に比べると、エラーについては正直 そこまで詳しくないという自負が
あります。エラーも歴史長いじゃん。
まあね。
エラー処理のプログラミングの 歴史イコールエラー処理の歴史
みたいなもんだから、それをちゃんと 把握はできてないなっていう思い
があるっていう言い訳をしてから スタートするわ。
もっと昔の言語は分かんないんだ けど、Cとかで言うと一般的って
言っていいのか分かんないけど、 帰り地のイントで判断ってやつだよね。
もっと言うと、イント。Cはもともと ブリアンという型はC99までない。
しかもC99のブリアン型もイント 入っちゃうんじゃなかったっけあれ。
draftcode
99か90かは覚えてないんだけど、 割と最近までないんだよね。
99ってやったっけ。99なんだっけ。 違う技のことを言ってる気がするんだ。
C99じゃない。99ってあったっけ。
Yoshiori Shoji
C99であった気がする。
draftcode
これも、このCのイントの 帰り地処理はちょっと苦い思い出があってね。
苦い思い出というか、自分のせい じゃないんだけど、これ誰かが悪いんだけど、
なんかBoolって書いてあんのよ。 キャピタルBoolよ。
UnderscoreBoolみたいなBoolで。
Win32APIとかをやってると、確か Windowsの環境ってBoolっていうのがあって、
BoolCoreってよくよく見たら、 なんでこれバグってんだろうってよく見たら、
その関数Boolを返すんだけど、 012を返すんだよ。
それぞれで違うのよ。012で。 三地論理なのよ、Boolなのに。
03:03
draftcode
なるほどね。
このイントで返すとかBoolで返す、 CでいうBoolで返すっていうのを見ると、
ああ、嫌な思い出があるなっていう 感じがするね。
Yoshiori Shoji
それはなんかあれだよね、 名前が間違ってるよね。
draftcode
そう、名前が間違ってるんだけど、 方がお気持ち、お気持ちセーブしかない。
Yoshiori Shoji
だとそうなっちゃうよね。 今なんか完全脱線しちゃうんだけど、
昔聞いた一番ひどい名前規則の話で、 メソッドでgetMD5っていうメソッドがあるんだけど、
呼ぶとシャワンが帰ってきてたらしいんだよ。
draftcode
すごい気持ちわかるよね。
Yoshiori Shoji
昔作ったときはMD5で実装されてたんだよね。
もっとセキュリティを上げなきゃいけないって言って、 内部の実装だけ変えるんだけど、
外まで公開するAPIをちょっと変えると 大変だみたいなのがあって、
残ってて、理由は想像できるんだけど、 確かにそれはひでえなと。
draftcode
すごい脱線するけど、getMD5、 いろんな意味でNGでしょ。
MD5、どっかでデータベースから 取ってくるんだったらgetMD5でいいよ。
その場でシャワンとかMD5計算するんだと、 ゲットで。
クリエイトじゃない、クリエイト。
いろんな意味でするっていうふうになる。
Yoshiori Shoji
ちょっと面白かったっていうのを思い出す。
エラーシェルの話に戻ると、 イントを返すみたいなので、
これってシェルとかのユニクスの コマンドもそうじゃん、基本。
ゼロが返ってくると正常で、 ゼロ以外だったらみたいなの。
draftcode
それも罠っちゃ罠だよね。
シェルだとしても認識できないけど、 ゼロは正常じゃん。
Yoshiori Shoji
普通は1が正常じゃん。
draftcode
これもフリップしてると言えば フリップしてるんだけど。
Yoshiori Shoji
歴史的定義というか。
ゼロ以外だったらエラー処理にするみたいな。
ゼロ以外でエラーコードみたいなの 表してるよね。
draftcode
そうだね。一応ゼロから255かまで 取れるからね。
Yoshiori Shoji
っていうのもあり、エラーは そういうふうにイントで表していた。
そうなるかコアダンプするしかなかった ってことだよね。
昔Cのコードを書いてたときは まずコアダンプして、
コアダンプしたからよしデバッグを起動しよう みたいなのでステップ実行して、
みたいなことしかできなかった。
draftcode
コアダンプもね、僕若者なんで、
まずモダンなLinuxでコアダンプが どこに出されるのかっていうのも
一応分かってない。
Yoshiori Shoji
俺ももう覚えてないわ。どこに出されるんだろう。
draftcode
なんか違うんだよね。
コアダンプ出す場所みたいなのが多分あって、
同じディレクトに測れるわけじゃない。
ハックスっても確かにあんのかな。
06:00
Yoshiori Shoji
設定あったはずな気がする。
draftcode
プラスコアダンプあってもどうしよう って思っちゃうもんね。
GDBの使い方はまず検索するところから 始まってみたいな感じ。
Yoshiori Shoji
本当の一番最初にプログラミングを覚えたときは
draftcode
そうやってGDBでやってたね。
Yoshiori Shoji
20年以上前だから覚えてない。
draftcode
ずっとね、もうプリントライフデバッグもどきで
ずっと過ごしてるからさ。
Java書いてるときもそうだったからさ、
デバッグは使えたほうがいいんだろうなと思いつつ、
Yoshiori Shoji
使った後は毎回忘れるから、
draftcode
コアダンプの世界は生きにくいなって感じがするな、自分は。
Yoshiori Shoji
それ俺逆にデバッガーがないと、
いろんな言語に言ってもまずデバッガーステップ実行
draftcode
どうやってやるのって思っちゃうからさ。
Yoshiori Shoji
多分あれだね。
前オブジェクト思考のときにも言ったけど、
どこで生まれたかによって、
俺は親がリスプみたいな感じだから
データ構図はすべてリストだと思ってるみたいな。
draftcode
ずっとどういうプログラムに書いてきたかによって、
プログラムっていうのは結局○○なんだって言って、
人によってはパイプラインデータ処理のことなんだって言うし、
人によってはこれはもう全部データベースオペレーションのことなんだみたいな感じで
生まれ育った、最初に見たプログラミングの手法を
親だと思って生きていくわけよ。
Yoshiori Shoji
ちょっとまだ脱線しちゃったけど、
コアダンプみたいなのがあって、
それとは別に俺はあんまり詳しくないんだけど、
グローバルエラーオブジェクトみたいなのを
プログラムで一個持っておいて、
エラーが発生したらそこを更新して、
そこが更新されたらエラーが発生したんだなって言って
処理をするみたいなのもあった。
draftcode
そうだね。
でもこれもシステムコードとかはそういうノリだよね。
Yoshiori Shoji
そうね。
あとVBAとかマイクロソフト系のAPIとかは
結構そっち系のをやるっぽい。
ラストエラー的な変数を作っておいて
そこに入れるっていうのを。
draftcode
一時期ずっとVBAを書くバイトをしてて、
黒歴史なんだけど。
やりすぎたんだけど。
プログラマーとしてプログラミングできるツールがあると
やりすぎちゃうっていうか、
一応チューリングコンプリートだと
チューリングコンプリートになっちゃうみたいなやつよね。
Yoshiori Shoji
チューブのテンプレートみたいな。
draftcode
ハンマー持ってると何でも釘に見えるやつね。
VBAも。
VB一応例外っぽい機構は確かあったはずなんだけど、
ごっちゃんになってたかな?
覚えてないなあまり。
そうだね。
ラストエラー系、グローバルオブジェクト系もね。
Yoshiori Shoji
グローバルオブジェクト系かイント系がもともとあった。
この辺はあれだよね。
09:00
Yoshiori Shoji
言語機構としてエラーハンドリングが組み込まれていないから
そうやってエラーを扱いましょうっていう、
みんなで決めてやってたっていうやつだよね。
draftcode
そうだね。
グローバルエラーオブジェクトみたいなのは
システムゴールだとしょうがないじゃん。
結局最終的にどっかのレジスタにセットされるみたいな感じで
カーネルに行った後に、この命令をやるとカーネルにビヨって
グイッて制御が飛んでみたいな話よね。
最終的にここにデータが入ってくるからみたいな感じになって。
このどっか的な、
まあもうこういう言語を触ることは現代ではないと実際言ってたけども。
現代ではないと。
言語的な仕組みとしてない時代はそうですね。
Yoshiori Shoji
次にエラー処理が言語に組み込まれるように
多分なってきたのがC++とかJava。
多分いわゆるキャッチ的なやつだよね。
トライキャッチとか練習やレスキューとかRubyでいうとね。
やってることは限定的なGoTo文だよね。
draftcode
虚勢されたGoToみたいな感じかな。
でもGoToって言っても我々あれだよね。
サブルーチンコールみたいな感じのGoToの使い方。
本当に関数という概念があまりなさそうみたいな感じの
非構造的なGoToと、
メソッド内だったら関数内だったらGoToできるみたいな
まだまだOKレベルのGoToもある中で。
これは結構メソッドとか関数を乗り越えた対極的なGoToなんだけど
まだ制御される感じのツールですね。
Yoshiori Shoji
GoToとしてはむちゃくちゃ使いにくいGoToだからね。
本当にGoToとして使おうとしたら。
draftcode
まあそうだね。
こういう例外を例外的状況以外で使うと良くないみたいな話も
よくないんですけども。
例えばPythonでいうストップイテレレーションエクセプションみたいなやつがあるんですけども
イテレレーションをストップさせるために例外を投げないといけないんだけども
これはアンチパターンでしょっていう
あまり例外的状況ではないところで例外を投げるっていうのは良くないみたいな。
そういった意味ではGoToっぽく使うこともある感じですね。
Yoshiori Shoji
これの便利だったイントとかで扱ったとき
イントで扱ったときよりも便利だったのはやっぱりあれだよね
メソッド呼び出しが連なってたとき
12:01
Yoshiori Shoji
AからBメソッド呼んでBからCメソッド呼んでみたいなときに
Cで発生したエクセプションをAの呼び出し元で
ハンドリングしたいみたいなときは楽だよね。
そうされたキャッチが大元でできるからみたいな。
draftcode
たぶんこのさっきのグローバルエラーオブジェクトみたいなのと
この構造可例外って言われるものの間にあるのが
セットジャンプ・ロングジャンプっていう仕組みがCにあって
それでフレームを乗り越えてバババって
フレームがアンワインドされるっていうのが
セットジャンプ・ロングジャンプって変なこと言うとちょっとあれだな
そんなイメージだった気がするんだけど
Yoshiori Shoji
もうCでお前間違ってるぞって言われても
draftcode
ダメージがあんまないからいいんだけど
そういうのが裏側にあって
それだとやっぱり使いにくいねっていうのがあるから
こういった構造可例外みたいな仕組みができたんでしょうっていう気がしますね。
Yoshiori Shoji
あとはあれだよね
コアダンプ起きた瞬間にもプログラムは何もできなくなるじゃなくて
コアダンプをプログラムがキャッチできるみたいな意味合いもあるよね
draftcode
かもね、確かに
Yoshiori Shoji
そこで止めるみたいな
draftcode
プログラム上でキャッチして状況を見れるとか
なんかあれじゃない?
よりアセンブラに近い方からプログラミングに入ったりとしては
このキャッチの仕組みって
CPUの上でどうやって実現されてるんだろうっていうのは
結構マジカルな感じの機構じゃない?
Yoshiori Shoji
すごい不思議だった、最初は
今も理解できてるのかって言われたら理解できてないけども
だから一番最初は本当に不思議で
でもGOTOと一緒なんだなって分かって少し腹落ちしたというか
GOTOも正確に言うと
本当のGOTOで52とかラインナンバーのGOTOじゃないやつって
だいたいラベルを貼ってそのラベルにGOTOするじゃん
だからTRYのところでラベルを貼ってあって
エクセプション出たらそこのラベルにGOTOしてるんだなみたいなのが
GOTOだっていうのが理解できるとイメージができてきて
なるほどなるほどみたいな
実際そうやって実装されてるかどうか分かんないけれども
脳内的には腑に落ちるようにはなった
15:07
draftcode
多分あれだよね、メソッドコール
関数呼び出しをするときの関数呼び出し規約で
エクセプションが起きた場合にどこにジャンプするかっていうのを
普通のリターンとは別に設けてるのかなっていう感じがするけど
自分も実装したことがないから勝手なイメージだけど
そうやって1フレーム1フレーム遡っていくんだろうなみたいな感じはするね
Yoshiori Shoji
これの一番めちゃめちゃでかい利点って
やっぱりUNIXの修了コードとか
UNIXのイントネリターンとかだとエラーが何なのかが分かんないんだよね
何にも
というかエラーの詳細情報とか分かんないの
スタックトレース的なものとかが
そういうのがちゃんとエラーという型ができて
スタックトレースも取れて
どっから発生したかが分かるようになったっていうのは
すごい画期的だよね
draftcode
大きな進歩だよね
大きな進化
特にJavaやってるとそうなのかなって思うんだけど
Javaやってるとそうなんだ
例外側だと結構言語を使ってそうなんだけど
スタックトレースさえ
スタックトレースが最低限見れないと厳しいみたいなのがあるんだよね
それに対してGoをやりたまにあげるんですけど
Goとかはスタックトレースがデフォルトで出なくて
マジで本当かよみたいな感じ
どうやってデバッグするんだみたいな感じはするけれども
スタックトレースが見えてさらに
いろんな情報を詰め込める
メッセージとかも詰め込めるし
何ならちゃんとエラーコードも詰め込めるし
高級な言語でいいですねっていう
Yoshiori Shoji
エラーという型ができたのは偉いよね
エラーのメッセージと種類と
スタックトレースが入ってるオブジェクトっていう
型が定義されたことは良かったなっていう気がする
ちょうど今やりたまにあげられてきたのでそっちの話に行くと
でも最近の言語だとキャッチ的なのはやらなくなってきたよね
draftcode
俺らが話す最近の言語はだいたいGoとラストにしか入れてるんだけど
Yoshiori Shoji
Goとラストしかないけどさ
これはさやっぱGoとない方がいいんじゃないっていう方向なのかな
draftcode
これもさ
なんかどうなんだろうね
Goとかラスト
型がどれくらいちゃんとつくかは
2つの言語で様々にバトってほしいんですけれども
でも基本的にタッチで返すというのとほぼ同じだと
18:00
draftcode
別に大して変わりはないですね
別に例外的機構もシンタックシュガーというか
本質的にそこまで変わりはないですよね
キャリーされる情報として何か大きな違いがあるかっていうと
別に違いはそこまでないっていう気がするんで
単純に人々の認識として
エラーを返すっていう値を返す
これも値を返すっていう方が正しいのかな
ファンクションプログラミングみたいなのが一般的になった
ファンクションプログラミング的な考え方
値を取ってその値に基づいた値を新しく返すっていう考え方になった結果
エラーも与えないよねっていう考え方が
より一般的になったのかなっていう感じがするから
戻り値としてのエラーというのを統一的に扱えるようにしようみたいな感じに
Yoshiori Shoji
いったのかなっていう気はするけどどうなんでしょうね
戻り値になるっていうただそれだけを聞くと
Cの時に交代したんじゃないみたいな感覚になるわけで
あれ?また返り値で戻るの?みたいな
それこそはmaybeもなどとかオプショナルとか
エラーハンドリングの一つなわけじゃん
値が取れたときと取れなかったときみたいなの無し
5だとハスケルで言うと
これさ俺読み方がよく分かってる
eitherでいいんだっけ
draftcode
either
Yoshiori Shoji
ハスケルでeitherを返すようなイメージだよね
draftcode
ライトとレフトが
僕はタッチと呼んでしまうけど
Yoshiori Shoji
タッチフルバリューズ
draftcode
コンベンションで最後はエラーになっているっていう感じだよね
Yoshiori Shoji
確かあれだよね
eitherもただ単にタッチを返せるっていうだけの
本当はモノドナだけなんだけど
みんなそれをエラー処理に使ってるっていうだけだもんね
そういう風に5とかラストがなってきてるよっていう話だよね
タッチで返しましょうって
draftcode
これも交代なのか
特にラストは型が欲しいっていう要請がすごくあるから
その型をちゃんとシグネチャーの中に入れたいというモチベーションからすると
変わり道に持ち込めてしまうほうがスッキリする
例外っぽくスローみたいな感じで投げたいんだったら
そういうのも確かあるんだよね
Yoshiori Shoji
パニックがある
あれはパニックで終わるだけか
draftcode
それは5のパニックだと思うけど
Yoshiori Shoji
ラストもパニックあるはず
21:02
draftcode
こうやってよく知らない言語の話をね
でもダウンストリームから来た
呼び出した先から来た何かヘダ打ちみたいなやつをそのまま受け渡すみたいな感じの
新たく的に実現できるし
例外っぽく見せなくても例外っぽい感じのフィーリング
書き心地を提供できるんだったらそれでもいいんじゃないっていう感じがする
例外的状況の値を型に入れたいっていうのはJavaでいう検査例外
非検査例外っていう
僕検査例外好きなんだけどみんな嫌いだったら嫌いって検査例外
こういった形で復活すると言っても良いので
型が付いてて検査例外やっぱり復活するんじゃんみたいな感じがするよね
Yoshiori Shoji
検査例外俺も好きなんだけど
Javaの検査例外の構文が良くないのは分かるが
このメソッド呼び出しの時にどんなエラーが出る可能性があるのかっていうのを
ドキュメントに書いてありますじゃなくて
ちゃんとプログラミング上から分かるっていうのはやっぱり素晴らしい仕組みだなって思っていたので
検査例外結構俺も好きだったんだけども
Javaの検査例外のちょっと良くなかったなと思う点があるとすれば
まず書き方だよね
どういう構文が良いのか分からないんだけど
draftcode
キャッチを必ずしなきゃいけないとかっていうのが多分
ちゃんと非検査例外と検査例外の使い分けみたいなやつを
ちゃんと標準が確立できなかったっていうのが手落ちかなっていう
Yoshiori Shoji
だからラストはもう全部検査例外にしちゃったみたいなもんなんだよね
draftcode
そうな気もする
Yoshiori Shoji
人類は適切に検査例外と非検査例外をきれいに設計できなかったから
あれこのエクストプションは検査例外なんだ
じゃあなんでこれ非検査例外なのみたいなのとか
今Javaも新しいフレームワークとかはどんどん検査例外使わなくなってるよね
draftcode
いくつか理由があると思うけども
さまざまな要請により
一番大きかったのはラムダとの相性がクソ悪かったっていう
自分の中では検査例外非検査例外は使い分けははっきりしていたんだけど
なかなか分かってる人に言うとそうだよねっていう風になるんだけど
分かってない人に言うと違いが分からないみたいな
24:01
Yoshiori Shoji
でも俺もある意味すごい分かりやすいなと思ってて
だってランタイムエクストプションを検証したらいい検査例外になるんだ
つまりランタイム実行時に発生する可能性の出るもの
実行環境とか実行の時間とか
そのタイミングによって発生するかしないかが分かれるものがランタイムなんじゃないの
draftcode
そういった例外は全部ランタイムしか起きない
ここで意見が微妙に分かれてるけど
いろんな意見があるということにしたい
僕の中では非検査例外っていうのは
もうこれ以上処理できない
これ以上キャッチとか書いて処理することはないだろうっていうような
ベールアウトしないといけない
非常にほぼトップレベルまで戻らないといけない
CLI的なツールだったらエグジットノンゼロだし
HPリクエストみたいなAPCみたいなリクエストだったら
5まで回るみたいなのにしないといけないときは
キャッチしない前提だからランタイムエクセプションを継承した何かにするし
逆にキャッチしてねっていう意図が
Yoshiori Shoji
これが起きたときの処理は書いてねっていう
draftcode
これはキャッチすべきだしキャッチすることを求めてるよっていう
大体キャッチするでしょっていうような例外を検査例外にするっていう
使い分けがあってだからコーラーからして
検査例外が返ってくるメソッドを呼ぶときはその場でキャッチして
かつそこで実際により情報の入った検査例外のエクセプションを
新しくラップして投げるか
もうこれ以上処理できないぜっていう風に投げて
ランタイムエクセプション的なものに変更するかっていうのが
判断が求められるっていうような仕組みだと思っているので
Yoshiori Shoji
それは理解できる
俺が言ってたランタイムエクセプションっていうのは一応補足すると
プログラミングが実行するときにこのメソッドを呼んだときに
必ずエラーになるのか
それとも呼ばれるタイミングとか呼ばれるパラメーターによって
エラーになったりならなかったりするときが
ランタイムエクセプションなのかなとか思ったんだけど
でもよく考えるとそうでもないなって思いながら
Javaの一番俺ムカついた検査例外で言うと
バイトコードをストリングに変えるときの
draftcode
エンコード?
エンコーディングの
Yoshiori Shoji
エンコードで
エンコーディングを後ろに渡すって
絶対キャッチしなきゃいけないじゃん
UTF-8のバイトの配列が入ってきて
それをUTF-8でエンコードってやったときに
必ずキャッチしろって言われるんだけど
俺キャッチしてもできることなんもねーんだよ
27:04
draftcode
これが本当に検査例外、非検査例外の
一番難しかったとこだなっていうので
アプリケーションを書いてるときは
まあいいのよ
非検査例外なんてあまり書かないんですよ
だって別にアプリケーション内部で
様々な階層があるわけでもないし
でもライブラリ作者として見ると
全部検査例外にしないと
もしかしたらライブラリ使ってる人
みんなこういう種類のエラーキャッチしたい
っていうことあるかもしれないしなー
っていうふうになっちゃって
全部検査例外っぽくなりがちだったりするんですよね
特に相性が悪いのはIoで
インプットストリーム、アウトプットストリームみたいなやつを
ライブラリエクセプションが入っちゃうんですよ
全部Ioがある可能性がある
Ioエクセプション汚染が非常にすごいことになってしまって
全部にIoエクセプションって書いてるっていう
もうどうしようもない状況なので
Yoshiori Shoji
しかもIo系はめんどくさいね
一緒にクローズも絡んでくるんだよね
draftcode
誰がクローズするの?みたいなのがあって
こいつは全部コンシームするから
こいつがクローズするんだみたいな感じで
本当かよ?みたいな感じで思いながら見てね
そういった意味で設計がすごく難しくなっちゃって
ライブラリのほうの
これはあんまり流行らないのかなっていう感じがするね
Javaの検査例外機構は
Yoshiori Shoji
一応Javaを擁護しておくと
クローズの件はトライリソースだけ
draftcode
トライリソースっていう
Yoshiori Shoji
あれでちょっとは良くなったよね
draftcode
そうだね
Yoshiori Shoji
忘れなくなった
draftcode
JavaはJavaでいいとこがあるんで
いいんですけれども
他方で自分はあんまりラスト書いてないから
Goは全部エラーだから
お気持ちでお気持ち処理すればいいんじゃないかなっていう
Yoshiori Shoji
よくあそこ叩かれるところではあるよね
叩かれやすい場所ではあるよね
draftcode
マインドセットとしては
なんとかなってればいいのよみたいな感じがするから
いいんじゃないですかね
公式ライブラリですら
あんまりエラーの周囲をちゃんと明示してるときって
あんまないような気がするし
エラーが起きたらもう
リクエスト500にして返すんじゃないのみたいな感じの
イメージがすごく強いんだよね
だからいいんじゃないみたいな感じで
みんなそこまですごい文句言ってるわけじゃなさそうな気がする
30:02
draftcode
唯一文句言ってるのは多分
唯一わかんないけど
スタックトレースが見れないみたいな感じの
が文句を言いがちだけれども
それも最近改善しつつありそうだから
Yoshiori Shoji
良かったねっていう感じですね
ちなみになんだけど
ちょっと話が戻るんだけど
いわゆるキャッチ的なもの
エラーハンドリング
エラー処理
言語に含み込まれたエラー処理から
そういうリターンチで
メビモなど的なもので表すようになってきた
立ちで表すようになってきたっていう流れって
なんで発生したのかが
俺いまいち理解できてなくて
キャッチのエラー処理が辛いって思ったこと
そんなにないのよ
検査例外非検査例外の辛さは
とりあえず別なので置いといても
キャッチでエラーを処理していたことが
辛いからやめましょうになったのか
例えば前々回話したけどさ
GOとかラストでもう継承なくなったよね
やっぱ継承は辛かったよねっていう話をしたじゃん
継承が辛いは
もういくらでも経験してるのよ
やっぱり
プログラミング書いてると
継承深くなるとそれ分かるよ分かるよ
やっぱ人類に継承早すぎたのは分かるんだけども
あんまりこう
GoTo的なエラー処理が辛いって思ったこと
そんななかったから
なんでそうなったのかな
いまいちまだ俺実感できてないんだよね
draftcode
なんか
うーんあんまり
そのユーザー視点で
何かが伝わったとか
そういうことじゃないんじゃないかな
なんかその
どちらかというと言語
自分の想像だけども
自分のキャッチとか
トライキャッチファイナリーみたいなやつで
辛いなみたいな
その機構自体で辛いなっていうのは
なくて
でもなんか
プログラミング言語を設計しようって
言った時に
例外処理機構みたいなやつを入れるよりかは
単純にメソッドコールの
一部のコンベンションとして
メソッドコールの中に全部含めてしまった方が
あの
呼び出し機構とかも
シンプルになるし
あと加えて言うと
あの
多分例外機構を入れると
コンパイルする言語って
その呼び出し規約的な
ものをどうするかみたいなのは
多分考えないといけない
だと思うんだよね
どうやってスタックを
マインドしていくかとか
どこにどんなドレスを入れるかみたいな
が必要になるのに対して
単純にもう全部メソッドコールとして
処理する
複数の値が返ってくれるとか
一つの値なんだけども
構造的な値が返ってくれるみたいな
世界にシンプルにしてしまった方が
そういった
例外機構によって
必要になる
本当にローレベルの呼び出し
スタック
関数
呼び出し規約みたいなやつをシンプルにできる
33:01
draftcode
から
良いっていう
とこあんじゃない
Yoshiori Shoji
確か例外って
draftcode
言語の実装としてってことだよね
そう実装として
言語のコンパイラーとか
コンパイラーとかの作者からすると
多分そういったところに
シンプリフィケーションが
するモチベーションが
あったりするんじゃないかな
特にリンクアーとかも考えるとそうなんじゃないかな
確かにね
Yoshiori Shoji
普通の
メソッドのリターン
の実装だけで済むわけだもんね
乱暴に言うと
draftcode
あとプラスして言うと
シープラプラって
例えばなんだけど
今そこまで
ストリクトじゃないらしいという話を聞いてるんだけど
Googleって
シープラプラの例外を禁止してる
Yoshiori Shoji
っていうことで有名
draftcode
そう
シープラプラ
好きな人は
なんでこんな
モダンな原画機能ディセーブルするんだ
みたいな感じなんだけど
僕はシープラプラをそこで書いてなかったから
なんともモチベーションが良くしてなかったんだけど
一応
遅くなるらしいんですよね
入れると
これは
FUDかもしれない
だから僕は詳しくないから
なんとも言えないけど
一部遅くなるらしいという話も
聞いたことがあるような気がしなくはないけど
まあ
単純に
事実として
機種を禁止だったっていう話もあったよね
Yoshiori Shoji
すごい厳密に言うと
確かに
トライみたいなのを書いたときに
メソッド呼び出し
これ以降でエラーが出たときは
ここに返ってくるよみたいなマークを付けて
みたいな処理は絶対に走るだろうから
draftcode
その分遅くなるとかなのかな
追加の処理ではあるよね
っていう気持ちがあるけど
Yoshiori Shoji
面白いのは
邪魔は禁止されてなかったんだよね
邪魔は禁止されたらどうしようもないから
draftcode
邪魔はVMだしね
そこまで
クリティカルではないという
話だと思う
Yoshiori Shoji
あと今
話しててちょっと
思いついたからこれが正しいかどうか
わからないんだけど
Goとかラストで例外処理がなくなって
帰り地に戻った理由の一つとして
並列処理
並列処理に
重きを置かれるようになったかな
ゴルーチンとか
邪魔もそうだけど
スレットのエラーをやむから
draftcode
キャッチできないじゃん
Yoshiori Shoji
でも
戻り地だったら簡単に扱えるじゃん
draftcode
エラーが発生しましたねって
扱えないのか
別に
邪魔だって
エグゼキューターに
クリックしたタスクから来たエクセプションは
ちょっと型はあるかもしれないけど
ちゃんと来るしね
36:01
draftcode
もう一回言っていい?
邪魔のエクセプションの話
他のスレットの
エクセプションを別スレットで
スローできるんですよ
だから
例えば
さっき言ったように
どっかのエグゼキューターにピッピッピッ
帰ってきた
それらのタスクの中から
よしこのエクセプション
コーラー側にスローしてやる
リスローすると
そのエクセプションのスタックトレース
別のスレットのエクセプションのスタックトレースが
Yoshiori Shoji
入ってる
draftcode
よくわからないところから
エクセプションが飛んできたけど
スタックトレースが
何言ってるのかよくわからないぜみたいな感じになってて
あれはね
知ってる人は
自分のエクセプションをスローしちゃいけないっていうのは
もうね
頭に入ってるんだけど
よくわからない人は適当にリスローしてるから
同じこと以上みたいなこと言ってるんだけど
ちげーんだよ
そういう文句もあったりとかね
そう
Yoshiori Shoji
そうなんで
そういうのとか結構エクセプションにしちゃう
いうわけだからキャッチしなきゃいけない
キャッチするみたいなエラーハンドリング処理にしてると
並列処理のときにちょっとややこしくなるのかな
っていう
draftcode
いやでもさっき言ったように
本質的には変わんないよ
本質的に
あれはシンタックシュガーだと思うんだけどね
書き心地は変わるよ
もしかしたら
書き心地は変わるかもしれないけど
本質的に情報が追加されたとか
リリースされたかっていうと
別にそんなことはないので
お好みの
現代の皆さんの
お好みの方法が
たまたま戻り値だったんじゃないかな
っていう想像をしますね
さっきのコンパイラー作者とかの要請を
別にしたら
Yoshiori Shoji
なんか
エラー処理を戻り値でやるって
でも
draftcode
あれじゃないの
逆に
エクセプションじゃなくても
エクセプションっぽいやつでもみんなそんなに
なんか
文句言わなかったねっていう
話ではあるんだよね
例えばさっきのC++の例外
禁止規約もそうなんだけど
例外を禁止してるってことは
例外以外の方法で
値を返さないといけない
エラーを返さないといけないから
実質同じだと思うのよ
エラーかどうかって
エラープラスなんとか
みたいな感じの
ものを返すわけなんだけども
C++でも
Abseilっていう
C++のGoogleのライブラリがあって
ステータスオアっていう
便利な
gRPCステータスを
または
オブジェクトっていう
よくわかんない
定義されてて便利なんですけど
そういう形で
エラーオブジェクトをまたは
本当の何かの値っていう風な
39:01
draftcode
感じで返すと思うけど
別にそれでいくんだったら
別にラストってそこまで変わんないじゃん
Yoshiori Shoji
現代の
タチを返すっていうのと変わんないよね
draftcode
C++に対しては
例外ディセーブするとは
みたいな感じで
微妙に
ディスられていたのか
ラストは別に
C++の例外禁止規約と
同じような
なのにあまりディスられてない
っていうのは
僕たちが見えてない何かを
見えていて
そこでが違いであるのか
それとも単純に人々
いいんじゃない?
それでもいい現代はっていう感じになってきたのか
それともみんな単純に
ラストが好きなだけなのかわかんないですけど
ここら辺はいいものだと思ってた人
かつ
ラストを最近書いている人に
Yoshiori Shoji
聞いてみたい感じがしますね
聞いてみたい気はするけれども
そういう
ちゃんとした理由があるんじゃなくて
多分だけども
ある機能
存在している機能が使えないっていうところに
対するただの嫌悪感な気がする
draftcode
そのさ
それだったらそれで別にいいのよ
好みの問題でした
っていうことだから
Yoshiori Shoji
たまにあるじゃん
俺もインターネットで
情報の噂でしか聞いたことないから
実体は見たことないけど
Java書いてるプロジェクト
なんだけどSI屋さんでラムダ禁止です
みたいなラムダは理解できないからみたいな
あると書かせろよ
書けるんだからみたいなさ
と同じ感じなんじゃないかな
って
あるんだから使わせろよ
なんで使わせられないんだよ
多分
GoogleのC++の
エクセプション禁止
を言っている人たちの
気持ちの大半はそれなんじゃないかな
draftcode
という気がする
これ分かんないからね
みんなの意見ではないから
分からんけど
まあ
みんなもうC++書きたくないって言ってるから
いいんじゃない
みんなもうラストで満足してるんでしょ
Yoshiori Shoji
っていう感じがするよね
Goとかラストにいって
実装者も
複雑さが減ったのかな
検証がなくなったり
とか
やっぱエラーハンドリング
キャッチ的なGo2がなくなったり
っていうのは
それ以外のところに
実装コストを避けるようになった
っていうのとかもあるのかな
draftcode
あるんじゃない
例えば
特にラストとかだと
シートのインターホップみたいな
総合ノリ入れみたいなやつ
気にするでしょある程度
ってなると
できるだけそういったファンシーな
機構がない方が
その
良いだろうっていう
気持ちは分かるのよね
あと
42:01
draftcode
かつ
現代の
プロカーニング言語って
必ずしも
X86とか
AMD64の上で動くものじゃなくて
トランスファイルされる可能性があるじゃないですか
何か忘れるとか
ウェーバーセンブリーだとか
ウェーバーセンブリーとかに
トランスファイルとか
邪魔する人に
トランスファイルみたいな
そういうのもあるのを考えると
より効率的に実行できる可能性が
低くなってしまう
可能性もあるんだよね多分
分からんけど
シンプルな呼び出し契約に
達成できるんだったら
それが良いというのは分かる気がする
オッカムのカミソリじゃないけど
無きでもいいんだったらいいよね
っていう
Yoshiori Shoji
ことなんじゃないかな
今の話で言うとちょっと気になったのは
ウェーバーセンブリー
Wasmとかに
ラストは
Wasmになるみたいなのは
結構最初の頃から
ラストの生まれが
Modulaだっていうのは
デカいと思うんだけど
Goって逆に他のとこに
トランスコンパイルするみたいなのって
draftcode
あんまり効かない気がするんだけど
そうだねでもGoはほら
シンプリシティを
目指した
ついてもいい言語だから
ないんだったら
ないほうがいいっていう
話だと思うんだよね
それ言ったら
Genericsまで最近なかったんだし
Yoshiori Shoji
Genericsむしろ入れなくて良かったのにね
draftcode
どうなんだろうね
あったらあったらいいかなって思うんだけど
なかったらなかったら
何々の書き方したねっていう
レベルの話だ気がしてくる
Yoshiori Shoji
全ての言語が似た機能を
全部持ってるとあんまり面白くないからさ
とんがってる言語の方が面白い
draftcode
エソテリック言語
エソ言語
愛好化していく
愛好していく
まあ
言語的な仕組みで
言うと
そういう
でもこう話してるとそんなに
大きく
変わったって感じはしないよね
最初の数字
数字から
なんかより
数字以上のものが
定義できるようになったっていうのが
だってシープラプラとかああいう時代でしょ
もしかしたら研究で
もっとなんかあんのかもしれないけども
少なくとも我々が日常的に
見てる言語の中で
見える例外処理機構
例外的状況を処理する機構っていうのは
なんかそこまですごい大胆な
進化があったかっていうと
そんなこともなさそうな
雰囲気を感じますね
なんか
もっと
エロ処理っていうものが
やっぱ大変なんだ
コード書いててもエロ処理っていうのは
結構
そこそこ占めると思うんだけども
45:01
draftcode
大変なんだっていうのと
そういったところに
より
良い機構というか
よりサポートされる言語機構みたいの
あってもいいのかなっていう感じはするけども
ないんだなっていう感じも
するね
Yoshiori Shoji
そうだね
今まで話してきたのってあくまでもさ
言語に実装された
どういう風にエラーを処理しましょう
っていうのを
言語に実装されているかの話じゃん
でさ
他方でさ俺むちゃくちゃ難しい
割にあんまり世の中でそんな話されてないな
と思うのは
エラーの設計だよね
draftcode
そうだね
あの
エラーの設計って言ったときに
もちろん言語内的な
プログラミング言語の中の
エラー設計の話もあるんだけども
もっと言うと
HTTPとかRPCでの
エラーっていうのを
どういう風に扱うか
設計するかっていうの
とか
もっと言うとモニタリングどうするよみたいな感じの
そうね
Yoshiori Shoji
モニタリングとかロギングにつながってくるんだよね
draftcode
そうそうそうそう
もっとその後半がさ
プログラミング言語内のさ
例外
例外回数が
みたいな話ももちろんそりゃそりゃ
重要なんだけども
サービスレベルの話をすると
なんか全体的にどうするよ
みたいな感じの
Yoshiori Shoji
話もあるんだよね
それこそさ
サーキットブレーカーとかを実現するためにはさ
それぞれのサーバー
適切にエラーが
ハンドリングされていなかったら
そもそもサーキットブレーカーが
うまく動かないわけじゃん
考えると
強調して
分散システムが強調して動くための
エラー設計とかって
結構ちゃんと考えなきゃいけない気がするんだよね
draftcode
そうなんだよね
Yoshiori Shoji
なんだけど
俺のアンテナが低いのかもしれないけど
あんまりそこについて
話されてない気がしていて
draftcode
あまりこう
そういったので
こういう処理方法がいいよね
こういうような構造がいいよねっていうのは
そこまで見ないような気がするんだけども
でもなんか
自分の中で
これはいいなっていう風に
思っているのは
HTTPみたいな
HTTPステタスコードみたいな
配送があるとすごく便利だなっていうのは
いろんなレベルで
感じていて
これはサービスレベルの
APIサーフェス
RPCとかの
APIサーフェスレベルの話ではあるんだけども
まず
なんか
HTTPのステタスコード
だいたい200番台300番台400番台500番台っていう風に
カテゴリー分けされていて
48:01
draftcode
基本的に400番台は
お前が悪いっていう
サービスの使い方が悪いっていう
Yoshiori Shoji
もうそのリクエストしてくんなって話してる
draftcode
500番台は
すまんおでが悪いっていう
そのさ
その400番か500番かっていう
この概念
お前が悪いおでが悪いっていう概念が
まずすごく良くて
対極的に
まずアラートを出したいって
言った時にはそのレベルで
カウントしてどういう風に
ちゃんと
返せるかみたいな感じの
話をまずアラートとしては
するんだけどもそれ以上に
アラートが鳴った時に
もっと詳細なエラーが
見たい結局
おれが悪いって言ってるんだけどどういう理由で
おれが悪いって言ってるのみたいな感じの
話をする時により詳細な
500番台の中のどれなのみたいな感じの
話ができると
非常に良いんだよね
で
この二重
二層構造多層構造でもいいんだけども
二層になってるっていうのが
非常に良いなっていう風に
このサービスレベルでのエラーを
考える時に思っていて
実際にこれを
Google見た時に
GRPC
ではないんだけど
GRPCステータスコードで
同じようなことをやっていて
SREの人には非常に
受けば良かった
まず
ステータスコード大雑把に
何が起こってるかっていうのは
把握できるのプラス
実際にこの500エラーみたいなやつが起きてる時は
実際はこのマイクロサービスだから
後ろのこのサービスが落ちてるから
何かエラーになってるっていうのが
その
本当にサービスレベルまで来てるっていうのが
クライアントサーフェスまで来てるっていうのが
非常に
二重の意味で人間の目でも見やすくて
かつアラートとしてもきちんと
何つっていうのは
このパターンはいいんだけども
あまり評判
あまり
HTTPステータスコードは
みんなデファインされてるからそれを使うんだけど
それ以上に細かい
そのレベルの
ステータス分けみたいなのはしないんだなっていうのは
ちょっと思うね
だから
例えば500なんだけれども
実際には別でイナムがあって
このイナムは
HTTPレベルでは500として返すんだけれども
500の中でも
これは実はデータベースコネクションエラーでっていうのを
内部で持ってると
Yoshiori Shoji
モニタリングとしては
draftcode
寺田 モニタリングとしてはすごい楽だよね
寺田 ただそれをやるためには
大きな
すごいたくさんのイナムを
定義しないといけなくて
Yoshiori Shoji
できる理由っていうのはいろいろあるから
寺田 しかもそれを
全てのサービスで共有しなきゃいけないから
寺田 そうね
draftcode
全てのサービスで共有まではしなくてもいい
その一つの
マイクロサービスの中で
ある程度そうすれば
分かるんだけれども
51:01
draftcode
そのイナムを
メンテナンスする
メンテナンスする必要もそこまでないんだけど
そういうイナムを作るっていうのに
みんな乗り気ではないんだなっていう
気がするね
一旦そういう仕組みができると
結構簡単にメンテナンスできて
モニタリングも
非常によく
見やすくなるので
いいなと思うんだけどあまり広まりませんね
Yoshiori Shoji
これは
寺田 今すごいいい話があったなと思って
400万台とか500万台の話
あれはエラー設計として
めちゃめちゃ俺も好きで
さっきの
マイクロサービス間の通信とか考えたときに
リトライをするかしないかの
判断とかもさ
400万台返ってきちゃったから
俺が悪いんだからリトライしてもだめだって
判断できるわけじゃん
マイクロサービスってどうしても
Ioを絡むから絶対に
リトライの機構って入れなきゃいけなくなるじゃん
どんなに頑張っても
draftcode
これも結構
会社によるのかもしれないんですけど
僕のエンジニアリングの経験は
結構Googleから来てるから
Googleのポリシーが
非常に僕の中のマインドセットで
奥深めてるんだけれども
少なくともGoogleのSRDポリシーは
リトライを細かいレベルでしない
リトライをするんだったら
本当に
ユーザーに近いところでしか
しないっていうようなポリシーがあって
というのも
すごい
マイクロサービス
とか
呼ぶみたいな設計になっていると
どっかでリトライをするってなると
それが
10個も20個も同じ
別の
マイクロサービスから呼び起こす可能性が
あって
あるレベルでリトライを
した結果
失敗して5回やって
失敗したっていうのを
次のレベルに持ってくると
そこでもまた5回やるんだけども
5回リトライするんだけど
そうすると5×5で
25回失敗行動が
満タンにするみたいな感じになっていき
どっかで
サーキットブレーカーがブレークするのかもしれないけど
Yoshiori Shoji
それがサーキットブレーカーが
draftcode
発動するやつじゃないの
それによってかなりグローバルアウテージが
可能性があるから
何回もするんだったら
本当にトップレベルで
するっていうような
例えば
10段階
全部でリトライしてると
やばいことになるし
すぐにブレーカーが飛ぶので
それは良くないっていう話
であるんでね
あとブレーカーが飛ばなかったところのサービスの
負荷が10倍以上になる
それがやばいっていうことで
あの会社は
SREのポリシーとしては
リトライはあまりしない
Yoshiori Shoji
なるべく上の方で
なるほどね
いやそう
ただ
54:01
Yoshiori Shoji
そう
G社さんはすごい特殊な環境だ
draftcode
そう特殊な環境なのもあるから
Yoshiori Shoji
一般的に言うとやっぱり
400だとリトライできなくて
500でリトライできるっていうのが
すぐ判断できる
サーキットブレーカーとしても発生してるエラーが
400が発生してるのか500が発生してるのかで
400だったら
このサービスだけぶった切ればいいや
になるし
全てのサービスちょっと待ってね
って止めたりもできるから
やっぱりその
大カテゴリーでまず
判断ができる
設計にされているっていうのは
めちゃめちゃうまい設計だな
っていう気はするんだよね
draftcode
まあ
スケールとかによるのかもしれないし
サービスによるかもしれないので
大まかな方針としてそういう風になっているのは
もちろん
結構ね
これも
いや
各サービスでね
皆さん脳みそを働かせて
何が一番いいポリシーなのかを考えてもらいたい
感じがしますが
いろんなパターンを知っておくっていうのは
いいことだし
いろんな
ところで
いろんな理由によりそういった選択をしているので
いろんなところを見れると
いいですねっていう感じがしますね
そうだから
Yoshiori Shoji
エラー処理って考えたときに
さっきさ
Cのときはintしか返さなくてだめじゃん
みたいな話をしてたけど
httpのステータスはまさにintなわけじゃん
そう
でも
なんだろうな
まずさ
よくわかんないけど100万台を
大カテゴリーにしましたっていう
その決定とか
別に1000万台でもよかったわけじゃん
でも
そのカテゴリーの分け方と
カテゴリーの割り振りが
めちゃめちゃ適切だったなと思って
200万台は成功です
300万台は
リダイレクトみたいな
移動です
400万台がクライアントのエラーで
500万台がサーバー側のエラーですっていう
カテゴライズも
めちゃめちゃ適切だなと思ってて
あれはすごい
綺麗な設計だなって思うんですけど
綺麗な設計だなって思うんだよね
draftcode
まあね
Yoshiori Shoji
まあそうだね
他方でさ
ちょっとそれを原理主義じゃないけど
綺麗だなってめちゃくちゃ尊厳してるからこそ
思うこととして
グラフQLとかGRPCとかさ
全部200で返すじゃん
draftcode
あのね
そこはちょっと
グラフQLは
グラフQLは
僕もうんって思うんだけど
GRPC用語過ぎたね
GRPCが
トランスポートとして
HTTP2を使っている
とかなんか
これなんか
不幸だったというか
しょうがなかった
200を返さないといけないっていうのも
57:01
draftcode
セマンティックス的にそうっていうのは
分かるんですよ
というのもHTTPって
どういうプロトコルかっていうと
最初に
レスポンスコードを返さないといけないんだよね
そうだね
RPCって
最後にレスポンスコードを返したいときがあるんですよ
Yoshiori Shoji
データをストリームで送ったりとか
draftcode
データをストリームで送って
Yoshiori Shoji
途中で障害が発生したときとかね
draftcode
あと
ここまでできたみたいな感じ
そうそうGRPCにストリームで
レスポンスっていうのもあるんだけど
ってなると
ちょっとセマンティックスが違いすぎて
最初に
レスポンスコードを返す
ステータスコードを返さないといけないっていうのが
非常に不便であるっていう
局面があるから
仕方なく
表面上200を返しているけど
ヘッダーで
ステータスコードを返すんだよね
そのGRPCでステータスコードは
そこそこ
僕が使ってた範囲で言うと
リーズナブル
そこそこリーズナブルだと
Yoshiori Shoji
僕は思っているんだけど
draftcode
まあそうだね
モニタリングっていう面で言うと
GRPC特有のモニタリングを
ロードバランサーとかで
しないと
ちょっと不幸なことになるだろうなっていう
感じがしますね
Yoshiori Shoji
ちなみになんだけど
話せるところまでで全然いいんだけども
GRPCがHTTP2の上で
乗っているようになる
前から当たり前なんだけど
プロトコルバッファーを使った
RPCは使ってたわけじゃん
社内では
っていう時がHTTP2上ではないわけじゃん
当たり前なんだけど
の時ってプロトコルは何の上に乗ってたの?
僕もね
draftcode
そこまでよく知らないんだけどね
でも別にTCPの上で乗ってたんじゃないの
Yoshiori Shoji
なるほどね
draftcode
でも
さまざまな
GRPCに乗っていて
あまり使われていない仕組みを
見た時に
これって会社内での
あれに対応してるやつだなっていうのは
なんか
つけてみえる
これ
そうだなっていうのは
あったりするけれども
たぶん会社の事情があるんでしょう
Yoshiori Shoji
っていう気がしますね
一方で
GRPCのステータスがあるとして
グラフQLは
あれだよね
draftcode
一応さ
グラフQLさ
そのグラフQLのモニタリングって
難しくない?
難しくない?
あんまりグラフQLのモニタリングをしたいっていうほど
スケール
うちの会社のスケールしないから
これどうやって
どういう考え方でモニタリングしようかな
みたいな感じになっていて
難しいんですよね
Yoshiori Shoji
だってね
QLを
ガッチャンコして投げれるじゃん
そもそも
1:00:01
Yoshiori Shoji
今あれだよね
ネットフリックスが使った
DGSをうちの会社は使ってて
それはもともと
モニタリングの仕組みが入ってるから
そのままそれをデータドックに送ってるんだけど
それはクエリとミューテーションごと
の
かかった時間みたいなのを一応送ってくれる
ガッチャンコされてようがなんだろうが
クエリ単位でのが
一応送られるようになって
それで遅いねとかは見れるようになってるんだけども
エラー率とかまで
出てくるとさ
クエリガッチャンコしたときの
ABCのクエリをガッチャンコしたときに
Bのエラーが出てたの
普通のグラフQLの
設計の
エラーハンドリングだと
ABCって呼んでCでエラーが出たときは
AとBはデータを返して
Cだけエラーを返します
みたいな
やり方もできるんだけども
多分あんまりやらなくて
ABC呼びをして
Cでエラーが発生したら全部エラー
返りますっていうか
キャッチモードでエラーが返ってきたらエラー処理に
走るみたいにするからさ
っていう処理になると
どこでエラー発生してるのかも含めて
モニタリング結構難しい気はするんだよね
draftcode
そもそもそうだね
まずエラーっていう
エラーのリクエストであるっていう
そうやってパーシャル
返さないんだったらディテールいいけど
グラフ系の
サーバー側の実装によっては
パーシャルで普通に隙間のときには
パーシャルで返せるようになってるはずだから
1リクエストだけで
0.3エラーって返せるみたいな
0.3エラーだったら
ダメみたいな感じする
みたいな感じの話もあるし
そもそもそうだね
どの
裏側でデータフェッチャーっていう概念があって
どのレベルで
何かエラーが落ちたかみたいな話は
多分出てくるんだけども
複雑になっちゃうし
このモニタリング
GRPCもそうなんだけども
Yoshiori Shoji
できないできないできない
draftcode
重大な欠陥があって
GRPCはまだせいぜい
HTTPヘッダーの中を見れば
そこそこモニタリングするための
ソリューションできる可能性はあるけども
SREの
帽子を被ると
極力ユーザーに近いところで
モニタリングしたいっていう
要求がやっぱりあって
あんまりモニタリングフレンドリーじゃないよね
っていう風にづくづく思うんだよね
あとそもそも
エラー処理の設計も
本当かなみたいな
感じになってるから
もしかしたらグラフQL
すごい使ってる人は
いやこれはスタンダードで
こういう風にすると一番いいんだみたいなのが
あるのかもしれないけれども
ちょっともんよりする感じの
APIですよね
Yoshiori Shoji
Facebookとかどうしてんだろうね
1:03:03
draftcode
グラフQLをよく使ってるという風に
されている
GitHubっていう
会社があると思うんですけども
あの会社絶対内部的には
グラフQL使ってないよねみたいに
よく思ってるんですよね
というのも
まず
GitHubのあのページはまずグラフQL使ってないから
お前ら
いいけどさ
お前らちょっとデータパリティ
そこら辺のデータ取れるパリティ
もうちょっと考えたほうがいいんじゃないみたいな感じ
Yoshiori Shoji
もしかしたら
iPhoneアプリとかで使うのだけ
draftcode
外に出してるのかもね
かもしれないけどね
なんかねえなみたいな時は
よくあるんだけどね
Yoshiori Shoji
なんか
グラフQLのエラーじゃないんだけども
話でFacebookの話で
聞いてて面白いなと思ったのが
グラフQLって当たり前なんだけど
外に出してるAPIだからさ
ユーザーが好きなように
組み合わせられちゃうわけじゃん
でクエリ投げれるわけじゃん
というのがあって
それってサーバー管理者としてはさ
ちょっとなんか
気持ちもあったんだけど
draftcode
でも多分Facebookは
公開APIとして
グラフQLエンドポイントを
公開
FacebookってAPIどんなの公開してんのか分かんないけど
なんか
多分自分だったらね
自分だったらクライアントが
出すグラフQLクエリって
もう
フロントエンドのビルド時に決まるわけじゃん
なんかそいつに
IDつけて
Yoshiori Shoji
モニタリングするよね多分
まさにおっしゃってるのと
同じような感じでFacebookって
クライアントが投げるっていうのを想定して
いる以外の
グラフQLのクエリが投げられると
エラーが発生するようになってるんだって社内では
ちゃんとそれをモニタリングしたいんだって
draftcode
そうだよねまともな運用しようと思ったら
Yoshiori Shoji
そうするしかないもんね
まともな運用しようとするとそうなるよね
って俺も思ったのよ
でもさそれって逆に言うとグラフQLの
柔軟性潰してるよねと思ってさ
draftcode
でもそれにもさまださ
スキルがあって
Yoshiori Shoji
わかるよ
draftcode
例えばなんか
今フロントエンド
ウェブフロントエンドと
クロムエクステンションがあるんだけども
クロムエクステンションもフロントエンドも
両方グラフQL APIを使っていて
別に同じデータを
同じようなデータをクリリしたいから
サーバーサイド変えなくても
これウェブフロントエンドで使ってるデータだから
が普通にあって
そういうのでなんかちゃんと
複数のフロントエンドとかで
クライアントサイドで共有できる
隙間がちゃんとあるっていうのは
Yoshiori Shoji
なんか非常にいい
draftcode
素晴らしい点
素晴らしい点なんですしちゃんとコンパイルすれば
なんか多分Facebookと同じように
このクリリしか来ないから
このクリリでモニタリングする
それで多分できるんだろうなっていう感じがする
でもパブリックAPIとしては
ちょっとなんか
1:06:01
draftcode
モニターするの大変だよね
Yoshiori Shoji
そうそう
なんかモニタリングの話になってきたなだんだん
エラー処理の話だったのに
draftcode
つながるんだよな
エラーはね
一続きだからね
何でもそうだけどさ
プロミスとかのさ
カウンターとかをつけたらさ
カウンターつけただけでさ
よく見れるようになったのに
それじゃ終わりないんだよね
そっからさアラート飛ばさないといけないしさ
アラート飛んだ時に何するかみたいなやつもね
ちゃんと見ないといけないし
ちょっと
続いてるからね
Yoshiori Shoji
続いてる
エラー発生したら終わりじゃないからね
特にウェブサービスとかはね
draftcode
だから
エラーハンドリング
というのを
でもあんまり
さっきもあんまり進化がないねっていう風に
言ってたけれども
こういったものを
これがいいプラクティスだよみたいな
もうちょっと
ちゃんと出ると嬉しいなっていう風な
感じはしますね
自分の中ではさっきの400500
構造化しようっていうぐらい
あとリトライとか
クォーターみたいな情報を
サイドチャンネルで
添付できる
例えばhttpヘッダーとかでちゃんと返すみたいな
いつリトライしていいとか
どれぐらいクォーターあるよみたいな
そういった詳細の
プログラマブルに取りたい情報は
ちゃんとプログラマブルに取れるようにして
プログラマブルに取ってほしくない情報は
プログラマブルに取れないようにする
みたいな感じの
どうするといいなっていう
感じですかね
Yoshiori Shoji
確かにエラーの中に
5秒後にもう1回トライしてねっていうのが
なんか構造化されて入ってたら
めちゃくちゃまた楽になる
じゃ楽になるよね
リトライしていいんだっていう
draftcode
この情報に依存して
コード変えてほしくないなっていうやつは
上手いとこなんか
依存できないような形にできないかなっていう
適当にヒューマン
ビジブルなエラーメッセージとかにできないかなっていう
Yoshiori Shoji
感じ
たまにあるよねキャッチした後さ
エラーメッセージのコンテインズとかでさ
draftcode
何が開いていったらみたいな
あれね良くない
良くないやつね
分かるよなんか
でもねサードパーティーのダブラリとか使ってるとね
Yoshiori Shoji
そういうのあるよね
まあまあ
だんだんずれてきたので
今日はこの辺にしとくか
あれだね話すことないって言ってたまでに結構話したね結局
draftcode
やっぱりね
思うところが
いろいろあるっていうか
あんま言語機構の話
そこまでなんかすごい思い入れだったかっていうと
思い入れはないけど
Yoshiori Shoji
そう
なんだろうね
面白いなとは思う
うん
draftcode
確かに
でもそうだなそういうの聞いてみたいな
やっぱり
出身研究室がさ一応プログラミング言語を
ゴニョゴニョするっていう
研究室だったから
1:09:01
draftcode
聞いてみたい感じですね
そういう研究があるんですかっていうのは
Yoshiori Shoji
気になる感じですね
ちょっと詳しそうな人
一人友達でいるから今度呼んでみるか
西尾博数
draftcode
なるほど
Yoshiori Shoji
多分詳しいと思うんだ
draftcode
なるほどね
Yoshiori Shoji
今度ちょっと話してみよう
呼んでみよう
よし
勝手に名前出しちゃったけどまあいいや
はい
draftcode
今日はこの辺にしますか
Yoshiori Shoji
お疲れ様でした
お疲れ様です
じゃあねー
