TypeScriptにResult型を導入するための妥協点はどこか？

現実のアプリケーションで発生するすべてのエラー・例外をResult型に変換するのは非現実的 エラーハンドリングが不要なものはUnexpectedErrorとしてまとめてしまう という現実的な落とし所を提案する記事です。 TypeScriptにResult型を導入したくなる理由 TypeScriptのエラーハンドリングは、try…catch文を使うのが基本です。tryブロック内でthrowされた例外はcatchブロックで捕捉されます。 try…catchによるエラーハンドリングには、以下の問題があります。 例外がthrowされる可能性がある関数かどうかが型シグネチャに表れないため、呼び出し時にtry…catchが必要かどうかわからない exceptionVarの型がunknown（設定によってはany）のため、エラーの種類に応じたハンドリングができない try…catchを細かく切って個別に

[mole-studio]

Promise時代ならいざ知らず、async/await使えるんだからtryで囲みましょう。そういう進化をするぞって皆でやってた業界でしょうに

[hirokinko]

一度はかかる麻疹のようなものと思っている。妥協の末疲れ果てて無理して導入することないかなと思うところまでがワンセット。

[takafumiat]

Rustのマネして複雑化してる

[soxandcity]

フロントエンドではそんな複雑なことをしたいケースに遭遇したことがないのでなんとも言えないですが、サーバーサイドでは素直に別の言語を使います

[matarillo]

ご参考 https://matarillo.com/dmmf/against-railway-oriented-programming/

[nazoking]

ユーザーに伝える必要のないエラーはそのままキャッチしなければ(あるいはキャッチして分別あるいは必要情報を追加してラップして再スローすれば)いいのでは？

[dorapon2000]

“UnexpectedErrorとしてまとめることで、予期しないエラーを一元的に処理できます。たとえば、予期しないエラーが発生した場合に、ログ収集サービスにエラーを送信する、といった”

[mak_in]

JSではどうかは分からないがResult型を使いたい理由は、①正常終了、業務エラー、システムエラーを分岐したい、②try-catchは性能が遅く、想定外も起こしやすいのでシステムエラーでのみ使いたい。面倒な時はTuple使ってる

[hasiduki]

Effect.ts使えばいいのに！！！！！！！