Elmで実行時例外は起きないからエラー監視は要らないは危険！
Webフロントで用いられるプログラミング言語Elmは、もっとも利用されているAltJSと比べて、いくつかウリとなる特徴があります。１つは実行時例外が原則起きないということが謳われています。
私もプロダクション利用を開始して２年ほど運用をしていますが、開発メンバーやQAのテスト・実行時において実行時エラーを検知することはありませんでした。(正確には１人のメンバーは、自分の環境の挙動に違和感を感じていました)
しかし、所詮はJavaScriptに変換され、HTML, CSSと共にブラウザという環境で利用されるに過ぎません。実際には、実行時例外は利用者の間で起きているのでした。
実行時例外の検知
Elmは性質上JavaScriptとのやりとりに一手間必要ということがあって、エラーモニタリングのツールSENTRYの利用はしていませんでした。しかし、サーバ側で検知しきれない不具合のためユーザ捜査のトラッキング利用目的でSENTRYを導入しました。そうしたところ、いくつかの実行時例外が検知されました。
今回検知できた例外
一番多くでていた例外は、以下のものでした。
Uncaught TypeError: Cannot read property 'childNodes' of undefined
こちらは、Elmで生成されたコードを純粋に動かす上では起き得ない例外です。おそらく、GrammarlyというChrome拡張によって引き起こされる例外でした。心情的には、開発者が起こしたコードではなくユーザの環境が引き起こした問題なので、対処はしていられない。というところですが、Grammarlyは非常に利用ユーザが多く、これからもプロダクト利用者が増える状況で無視はできません。
そのため、以下のようなGrammarlyを無効化するカスタム属性を付与したtextareaを用意して、使用することにしました。
-- escapeTextArea [ class "test" ] [ ]
escapeTextArea : List (Attribute msg) -> List (Html msg) -> Html msg
escapeTextArea attr html =
textarea (Attr.attribute "data-gramm_editor" "false" :: attr) html
例外が起きるのでは、Elmを使う意味はないのか？
Elmでも利用する上で実行時例外は起きると認識した上で、やはり原則例外が起きないのは強みだと思います。なぜなら、JavaScriptを生に近い形で使えば使うほど、ちょっとしたライブラリやコードの変更でも例外を埋め込んでしまう確立は上がってしまいます。
Elmでは生成されるコードのパターンが決まっているので、決まった例外パターンに対して対策を施せば、多くのユーザ体験には支障がない成果物をリリースすることができます。
どのようにElmを運用していくべきか
まずは通常のWebアプリケーションとして、モニタリング(筆者はSENTRY)をしましょう。出てきた例外に対して、すでにある対策を行ったり、新種の例外は積極的にコミュニティに報告をしていきましょう。
まとめ
多くのユーザが触れるアプリケーションでは、開発チームのテストで過信してはいけません。十分すぎるぐらいモニタリングや情報収集をして対策を行いましょう。上手くElmを利用して、ユーザ体験を守りましょう！
Discussion