2

ZIO( https://zio.dev/ ) は、コアにデータ構造を持つ scala フレームワークでありZIO[R, E, A]、そのサイトは 3 つのパラメーターについて次の情報を提供します。

ジオ

データ型には、次のZIO[R, E, A]3 つの型パラメーターがあります。

  • R- 環境タイプ。この効果には type の環境が必要Rです。この型パラメーターがAnyの場合、効果は任意の値 (単位値など) で実行できるため、効果に要件がないことを意味します()。
  • E- 障害の種類。効果は type の値で失敗する場合がありますE。を使用するアプリケーションもありますThrowable。この型パラメーターが Nothingの場合、Nothing 型の値がないため、効果が失敗しないことを意味します。
  • A- 成功タイプ。効果は type の値で成功する場合がありますA。この型パラメーターがUnitの場合、効果は有用な情報を生成しないことを意味し、 の場合Nothing、効果が永久に (または失敗するまで) 実行されることを意味します。

何が何であるかを理解するのは簡単Aです。これは、名目上のケースで関数によって返される値です。つまり、関数をコーディングした理由です。 Rは一種の依存性注入です - 興味深いトピックですが、ZIO常に設定することで無視して使用できますAny(実際にIO[E, A] = ZIO[Any, E, A]は lib にエイリアスがあります)。

したがって、それEはエラー用のタイプのままです (有名なエラー チャネル)。私は大まかにそれIO[E, A]が一種だと思いますEither[E, A]が、効果を扱います（これは素晴らしいです）。

私の質問は次のとおりです。アプリケーションでどこでもエラー チャネルを使用する必要があるのはなぜですか?また、エラー チャネルに何を入れるかをどのように決定すればよいでしょうか?

4

1 に答える 1

7

1/ なぜエラー チャネルで管理に影響するのですか?

開発者として最も困難なタスクの 1 つは、何がエラーで何がアプリケーションに含まれていないかを判断することです。より正確には、失敗モードを発見することです。アプリケーションで後で何らかの方法で処理できるエラーと、アプリケーションで処理できない予期しないエラーとは何か。その質問に対する決定的な答えはありません。それはアプリケーションとコンテキストに依存するため、決定する必要があるのは開発者であるあなたです。

しかし、最も困難なタスクは、その約束を守るアプリケーションを構築することです (何がエラーで、何が公称パスかを選択したため、約束です)。それは驚くべきことではありません。 2 週間 - ほとんどの場合、推測せずにコードが何を行うかを理解し、エラーへの対応を含め、その動作に適応するための手段を用意します。

これは難しく、考えられるすべてのケースに対処するための体系的なプロセスが必要です。

バイモナドのエラー チャネルIO(したがってZIO) は、そのタスクにIO役立ちます: モナドは、ほとんどのエラーの原因である影響を追跡するのに役立ち、エラー チャネルは、考えられるエラー ケースを明示します。アプリケーションの一部には、可能であればそれらに対処する機関があります。明示的な障害モードを使用して、純粋で一貫性のある構成可能な方法でエフェクトを管理できます。さらに、 の場合、ZIOレガシー Java のような非純粋なコードを非常に簡単に簡単にインポートできます。

val pure = ZIO.effect(someJavaCodeThrowingException)

2/ エラーを選択するにはどうすればよいですか?

したがって、エラーチャネルは、what if?そのコードに取り組んでいる将来の開発者への質問への回答をエンコードする方法を提供します。「データベースがダウンしたら？」「あるDatabaseConnectionError」。ただしwhat if、現在のアプリケーション レベルのユース ケースでは、すべてが同じというわけではありません。「ユーザーが見つからない場合は?」- ああ、それは低い「リポジトリ」レベル (何も見つからなかった「検索」など) で完全に予想される回答である場合もあれば、他のレベルでのエラー (プロセス中の場合など) である場合もあります。ユーザーを認証するために、実際に存在する必要があります)。最初のケースでは、エラー チャネルを使用しない可能性があります。2 番目のケースでは、エラー チャネル ( UserNotFoundError) を使用する可能性があります。

前述したように、エラー チャネルのエラーは通常what if、アプリケーションで処理する必要がある可能性がある質問のためのものであり、その関数レベルではありません。の最初の例はDatabaseConnectionError、アプリ内でより高くキャッチされ、「再試行してください」などのユーザー メッセージと、sysadmin への通知メール (「すぐに確認してください。ここで何か問題があれば」) につながる可能性があります。これUserNotFoundErrorは、ログイン フォームでユーザーのエラー メッセージとして管理される可能性があります。たとえば、「ログインまたはパスワードが正しくありません。再試行するか、そのプロセスで資格情報を回復してください」などです。

したがって、これらのケース (公称誤差と予想誤差) は簡単な部分です。what ifしかし、レベルに関係なく、アプリケーションがどのように答えればよいかわからない質問がいくつかあります。「そのオブジェクトを割り当てようとしたときにメモリ例外が発生した場合はどうすればよいですか?」何の手がかりもありませんし、実際、手がかりがあったとしても、それはそのアプリケーションで扱いたいものの範囲外です。したがって、これらのエラーはエラー チャネルには入りません。私たちはこれを失敗と呼び、アプリケーションをクラッシュさせます。これは、アプリケーションが未知の危険なゾンビ状態になっている可能性が高いためです。

繰り返しますが、その選択 (公称パス/エラー チャネル/障害) はあなたの選択です。2 つのアプリケーションが異なる選択をする可能性があります。たとえば、1 回限りのデータ処理アプリを破棄すると、すべての非名目パスが失敗として扱われる可能性があります。リアルタイムでケースをキャッチし、それが重要かどうかを判断する開発者がいます (シェル、Python、およびその戦略が頻繁に使用されるスクリプトを参照してください。エラーをキャッチする開発者がいない場合でも:)。亡霊の反対側では、Nasa の開発者はすべてをエラー チャネル (+) に入れました。メモリの破損も含まれます。これは予想されるエラーであるため、アプリケーションはそれを処理して続行する方法を知る必要があります。

(+) 注: 知る限り、彼らは (今のところ) zio を使用していませんが、何がエラーであるかに関する決定プロセスは、C でも同じです。

さらに話を進めると、私 (@fanf42) がScala.ioカンファレンスで講演を行いました。「アプリケーションにおけるシステマティック エラー管理」という講演は、フランス語 でここから入手できます。はい、フランス語ですが、英語のスライドは こちらから入手できます。そして、私に ping を送信してください (スライド デッキの最後にある連絡先情報を参照してください)。

于 2020-09-02T19:48:32.653 に答える