Result型を用いたエラーハンドリングの是非

[KentaHizume]

背景

GoやRustには組み込みでResult型が存在し、これを用いたエラーハンドリングが好まれているらしい。関数型プログラミングとの相性がよいと言われている。伝統的なTypeScriptのエラーハンドリングは、Error型とtry-catchを用いたものだと思われるが、TypeScriptでも自作のResult型を作ることで似たような実装が可能である。しかし、賛否両論あるように見えるので、意見を収集したい。

TypeScriptに安易にResultを導入しない方がいい
とりあえずTypeScriptの例外処理にはResult型を使っておけ
Axios のレスポンスを Result 型で受け取る

論点

• Dresscaフロントエンドにおいて、Result型を用いたエラーハンドリングを行うべきか

ゴール

• Result型を用いたエラーハンドリングに対する現時点でのスタンスを説明できること

制約

特になし

[tsuna-can-se]

これはエラーをプログラム上でどのように表現するか、という話に集約されると思います。
エラーにはシステムエラーと業務エラーがありますが、TypeScriptではシステムエラーを例外で表現します。
業務エラーをプログラム上どのように表現するかは、通常プログラム言語としては決められていません。

プログラム上でエラーを表現する方法は例外と戻り値の2パターンがあります。
例外にすると、エラーを集約してハンドリングするような処理が実装しやすくなります。
戻り値で表現すると、業務コード内で戻り値をベースにプログラムを書くことが強制できるというメリットがあります。
ただ、レイヤーが複雑化すると、戻り値を呼び出し元に伝搬するようなコードを大量に書かなければならず、生産性が悪化しやすいです。

[KentaHizume]

@tsuna-can-se
コメントいただきありがとうございます。

TypeScriptではシステムエラーを例外で表現します。

GoやRustの場合はシステムエラーを戻り値で表現するような設計哲学に基づいている一方で、
TypeScriptは例外で表現するような設計哲学に基づいているので、
少なくともシステムエラーに関してはResult型を用いることはできない

業務エラーをプログラム上どのように表現するかは、通常プログラム言語としては決められていません。

業務エラーに関しては例外と戻り値の2つから選ぶことができる
（そして、それぞれメリットとデメリットがある）という理解で合っておりますでしょうか？

[tsuna-can-se]

業務エラーに関しては例外と戻り値の2つから選ぶことができる
（そして、それぞれメリットとデメリットがある）という理解で合っておりますでしょうか？

はい、まったくその通りです。
ただ、近年はどちらかというと例外に倒して取り扱うケースが多いように感じています。
例えば.NETの場合、業務エラーは戻り値で、システムエラーは例外で表現することを前提に言語設計がされていますが、戻り値で業務エラーを取り扱うのは煩雑であるということから、例外で表現するケースがほとんどです。
Javaの場合、業務エラーもシステムエラーも例外で表現することを前提に言語設計がされています。

ただ、これらはプログラムが複雑化しやすいバックエンド側のプログラムを前提としているからかもしれません。
クラス構造がフラットであればあるほど、業務エラーを戻り値で表現することのメリットが強く出てきます。
フロント側も最近はプログラムが複雑化してきているので、もしかしたら例外のほうが取り扱いやすいケースが多くなるかもしれませんね。

[KentaHizume]

個人的にはResult型よりも従来のError型とtry-catchのほうがよいと考えています。
気になっている論点は下記です。

• try-catchを排除しきれない
  • Result型ではtry-catchを排除できると言われているが、実際にはそうでもないという記事がある
• Result型が組み込み型ではない
• 場合によって使い分ける混合戦略の運用負荷が高い
  • こういう場合はこっち、というのをチェックする負荷がかかる
  • 関数型プログラミングは学習曲線がきつい（と思っている）
• 従来型において、デコレーターを用いて実装を簡略化できる見込みがある
  • 従来型はResult型より実装が面倒というデメリットがあるが、これが緩和できる