前置き
いい加減コイツを前に進めねば・・・・・・・・というアレね。
で、有り難いことにPRに要点をまとめてくださっており、フムフムなるほど〜って言いながら読んでみたのですが、マージするに当たってはちゃんと自分の目でも確かめてみないと何とも言えんっていう。
ポイントを掴めた状態で読んでいけるのは有り難い！！
Updates for CakePHP 4 by BGehrels · Pull Request #34 · Connehito/cake-sentry · GitHub
内容をちゃんとまとめたらcake縛りブログに移そうかと思っているけど、とりあえず雑にでも良いからメモを残したい意図でコチラのブログに書きます。
cake3でエラーロガー作った時も同様の調査をしており、「どういう風に流れるか」を掴んでおくと「どういう風に干渉すれば良いのか」が見えるので、やろうと思いました。↓はその時に書いたやつ。
まだcake3歴が浅いタイミング*1だったので探り探りで書いてるやつだなーって印象があるけれども。ErrorとExceptionの差とかもそこまでよく分かってなかった時だぁ〜
で、これと同じようなことを、これと似た動機*2でやっておこーぜというわけです 。ﾜｸﾜｸ
なので最重要なのは「エラー処理の流れを追うこと」だ、と。
本題
まずはwebのException、弱いエラーをそれぞれ見ていきます
Exception
今回は PagesController::display() の中から \RuntimeException を投げてみる
とても良かったのは、cake3の時期に比べてMiddlewareがLoggerに直接依存していたところが解消されていて、ErrorHandlerの(名前の通りの)存在感が増した所です。
(↓のPRの参照)
と同時に、「ErrorHandlerMiddlewareでキャッチされた例外にリクエストコンテキストを扱ってLogに残したい」というのが、コレまでは「Middlewareごと拡張する」という方法しか無かったのも解消しています。
ErrorHandlerはErrorLoggerに対してRequestオブジェクトを渡してくれるんです。やったね！
弱いエラー
同じく、 PagesController のアクション内で trigger_error() をした感じです。
とてもシンプルでいいですね！
なお、エラーレベルによっては(=致命的なエラーの場合は)、handleError()内で処理が変わるので注意が必要。注意、といっても「そりゃそうだよね」って感じですが 💨
補足: set_erro_handler / set_exception_handler
ハンドラの登録ですが、これは BaseErrorHandler::register() で行われます。
という訳で、基本的には config/bootstrap.php 内の処理として、ハンドラが登録される感じです。
終わり
これと同様にConsole系の処理も追う必要があるのですが、今回は取り敢えずやりたいことが出来たのでwebのみの内容に絞って放出してしまいます・・
ErrorHandlerとエラー用のLoggerがどのタイミングでセットされるか？というのも合わせて抑えておくことで、cakeのエラー管理をしっかり行いやすくなると思います。
*1:といっても2018-03なら半年くらいか？業務で必要だったから「エラーを捕まえてSentryに飛ばすようにする」はこの時期だと既に作れていたような気もするんだけど、どうなんだろ。
でもPhpStormをちゃんと使うようになったキッカケの1つだったのは覚えてる！
*2:ず〜〜〜〜〜っとcak4対応やらねばやらねば！！と思っていて滞っていたわけですが、コレの理由の大きな1つが「CakePHP4への変更のキャッチアップをシないといけない、大変そう・・」というところで億劫になってしまっていた面があり。こういう時に、自分が直接のユーザーに慣れていないプロダクトつらいですね。。
ただ、「よく考えてみたらエラーハンドリング周りとプラグイン周りの2箇所だけ追えば、あとは動くな？」という事にふと気付きました。
あと、とにかく「使ってみてもらえるようにして、フィードバックを集められるようにする」方が大事かも知れん。
