--- schema_version: "1" id: 2718f9abffec751eec9b5713a3e24bd41bbb00a06b3b0344562745ef5dc41909 title: "Mule 4 の概要: エラーハンドラー" collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/mule-runtime/4.7/intro-error-handlers.md canonical_url: https://docs.mulesoft.com/jp/mule-runtime/4.7/intro-error-handlers source_site: docs.mulesoft.com content_type: documentation content_hash: f45a77a46f89c1cd53426a352c0b8bef34526b3e8220ac183d7cb1a1e47f1552 description: MuleSoft Documentation Site release: "4.7" latest: false --- # Mule 4 の概要: エラーハンドラー Java の例外処理プロセスでは何が起こったのかを理解するためにソースコードを確認したり、エラーを強制的に発生させたりする必要がありますが、Mule 4 ではこれ以外の方法も使用できるようになりました。Java の ​`Throwable`​ エラーや例外も引き続き使用できますが、Mule 4 では処理しやすいエラーの概念が正式に導入されています。スローされる可能性のあるエラーの種類を各コンポーネントで宣言して、設計の時点で潜在的なエラーを識別できるようになりました。 ## [](#mule-エラー)Mule エラー 実行に失敗すると、Mule に次のコンポーネントを含むエラーが示されます。 - 問題の説明。 - 問題の特性を表す種類。 - 原因 (失敗を引き起こした根本的な Java ​`Throwable`​)。 - エラーメッセージ (省略可能)。問題に関する Mule の適切なメッセージが記載されます。 たとえば、HTTP 要求に失敗して 401 状況コードが表示された場合、Mule エラーに次の情報が示されます。 Description: HTTP GET on resource ‘http://localhost:36682/testPath’ failed: unauthorized (401) Type: HTTP:UNAUTHORIZED Cause: a ResponseValidatorTypedException instance Error Message: { "message" : "Could not authorize the user." } ## [](#エラーの種類)エラーの種類 上記の例では、エラーの種類は単純に ​`UNAUTHORIZED`​ ではなく ​`HTTP:UNAUTHORIZED`​ です。エラーの種類が名前空間と識別子の両方で構成されるため、ドメインからその種類を判別することができます (​`HTTP:NOT_FOUND`​、​`FILE:NOT_FOUND`​ など)。名前空間はそのコネクタによって定義されますが、コアランタイムエラーの名前空間は暗黙的なため、​`MULE:EXPRESSION`​ と ​`EXPRESSION`​ は同一とみなされます。 エラーの種類のもう一つの重要な特徴は、親種別のある可能性があることです。たとえば、​`HTTP:UNAUTHORIZED`​ は親として ​`MULE:CLIENT_SECURITY`​ を持ち、さらにその親として ​`MULE:SECURITY`​ があります。このため、エラーの種類がグローバルなエラーの細部であることがわかります。つまり、広範なセキュリティ問題の 1 つにクライアントセキュリティエラーがあり、その 1 つに HTTP 未承認エラーがあるということです。 こうした階層により、大まかなルーティングが可能になります。たとえば、​`MULE:SECURITY`​ のハンドラーが HTTP 未承認エラーと OAuth エラーの両方をキャッチします。以下は、コアランタイムがどのような階層になっているかを示しています。 ![ANY や CRITICAL などのカテゴリが表示されているエラー種別の階層](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-hierarchy.png) どのエラーも一般的なエラーと ​`CRITICAL`​ エラーのどちらかに該当しますが、後者は極めて深刻なため処理することができません。一般的な階層の最上位が ​`ANY`​ で、その下位の全種類がこれに該当します。 ここで重要な点は、失敗の明確な理由が見つからない場合に使用される ​`UNKNOWN`​ という種類に注意することです。このエラーは ​`ANY`​ 種類経由でしか処理できないため、今後既存のアプリケーションの動作を変更することなく、不明なエラーを特定できるようになります。 コネクタについては、各コネクタがそのコアランタイムエラーを考慮して各自のエラー種類階層を定義しますが、​`CONNECTIVITY`​ と ​`RETRY_EXHAUSTED`​ の 2 種類はすべてのコネクタに共通するため、常に存在します。 ## [](#error_handlers)エラーハンドラー Mule 4 では、​`error-handler`​ コンポーネントを導入してエラー処理が再設計されています。このコンポーネントには任意の数の内部ハンドラーを含めることができ、最初に一致したハンドラーにエラーをルーティングできます。これらのハンドラーに該当するのが ​`on-error-continue`​ や ​`on-error-propagate`​ で、どちらもエラーの種類 (あるいは数種類のエラー) または式 (高度なユースケースの場合) との照合をサポートしています。こうしたハンドラーは、Mule 3 の選択例外 (​`choice-exception-strategy`​)、キャッチ例外 (​`catch-exception-strategy`​)、ロールバック例外 (​`rollback-exception-strategy`​) 戦略によく似ていますが、はるかにシンプルで一貫しています。 Mule 4 でエラーが生じると、エラーハンドラーが実行され、最初に一致したハンドラーにエラーがルーティングされます。この時点でエラーが検査されるため、使用するコンポーネント (Flow または Try スコープなど) に応じたハンドラーを実行して処理できます。 - `on-error-continue`​ が実行され、実行の結果がそのオーナーの結果として (オーナーが実行を正常に完了したかのように) 使用されます。 また、この時点のすべてのトランザクションがコミットされます。 - `on-error-propagate`​ はすべてのトランザクションをロールバックしてから実行され、その結果が使用されて既存のエラーが再度スローされます。つまり、そのオーナーは「失敗した」とみなされます。 HTTP リスナーが、HTTP 要求を実行する別のフローへの Flow Reference コンポーネントをトリガーする、次のアプリケーションについて考えてみます。メッセージの受信時にすべてうまくいけば (下図の 1)、参照がトリガーされ (2)、要求が実行されて (3)、応答を正常に受信します (HTTP 状況コード 200) (4)。 ![NOT\_FOUND が含まれる HTTP エラーのエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-example-1.png) エラーハンドラーの設定が ​`inner-flow`​ であるため HTTP 要求に失敗し、​`HTTP:NOT_FOUND`​ エラーが表示された場合 (下図の 3)、エラーが伝搬され (4)、Flow Reference コンポーネントが失敗します (2)。ただし、​`primary-flow`​ によって ​`on-error-continue`​ を使用してエラーが処理されるため、含まれている Logger が実行され (5)、正常な応答 (HTTP 状況コード 200) が返されます (6)。 ![NOT\_FOUND が含まれる inner-flow の HTTP エラーのエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-example-2.png) 要求に失敗し、未承認エラーが表示された場合は (3)、​`on-error-continue`​ により ​`inner-flow`​ が処理を行い、ファイルから静的コンテンツを取得します (4)。そして、Flow Reference コンポーネントも正常に行われ (2)、正常な応答 (HTTP 状況コード 200) が返されます (5)。 ![UNAUTHORIZED が含まれる inner-flow の HTTP のエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-example-3.png) では、HTTP 要求で別のエラーが生じた場合はどうでしょうか? このフローには ​`NOT_FOUND`​ エラーと ​`UNAUTHORIZED`​ エラーのハンドラーしかありませんが、デフォルトで他のエラーも伝搬します。つまり、スローされたエラーに一致するハンドラーがなければ、エラーが再びスローされます。たとえば、要求に失敗し、「メソッドが許可されていません」というエラーが表示された場合 (3)、このエラーが伝搬され、Flow Reference コンポーネントが失敗し (2)、この伝搬により応答も失敗します (4)。 ![失敗応答になる HTTP のエラー処理設定が表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-example-4.png) 上記のシナリオを回避するためには、最後のハンドラーを ​`HTTP:UNAUTHORIZED`​ ではなく、​`ANY`​ と照合するようにします。以下は、​`HTTP`​ 要求で生じる可能性のある全エラーがどのように提示されるかを示しています。 ![On Error Continue の ANY などの種別が含まれる \[General (一般)\] 項目](_images/error-handling-any.png) また、項目の場合は、 式を使用してエラーを照合することもできます。たとえば、エラーの処理時に Mule エラーを使用できるため、このエラーを使用してすべてのエラーを HTTP 名前空間と照合することができます。 ![HTTP エラーを処理する式が表示されている On Error Continue の 「General (一般)」 項目](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-expression.png) ## [](#try-スコープ)Try スコープ Mule 3 では概してエラーをフローレベルでしか処理できないため、エラーに対処するためにはフローにロジックを抽出する必要があります。Mule 4 では、フロー内で内部コンポーネントのエラーのみを処理する Try スコープが導入されました。このスコープは旧来の Transactional スコープの後継で、トランザクションもサポートします。 ![エラーの伝播と設定を行うコンポーネントが含まれる Try スコープが表示されているフロー](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-try.png) 前の例では、On Error Propagate コンポーネントがデータベース接続エラーを伝播するように設定されているため、​`try`​ が失敗して、フローのエラーハンドラーが実行されます。 On Error Continue コンポーネントは、他のすべてのエラーを処理するように設定されています。この場合、Try スコープの実行は正常に完了し、フローの実行が次のプロセッサーである HTTP Request 操作に引き継がれます。 ## [](#エラーのマッピング)エラーのマッピング Mule 4 では、デフォルトのエラーをカスタムエラーにマップできるようになりました。Try スコープは便利ですが、同一のコンポーネントがいくつかあり、それぞれのエラーを区別したい場合、これらのエラーに Try を使用するとアプリケーションがわかりづらくなることがあります。この場合は代わりに、各コンポーネントにエラーマッピングを追加することが考えられます。つまり、コンポーネントからのすべてまたは一定のエラーストリーミングが任意の別のエラーにマップされるようにします。たとえば、それぞれ HTTP 要求コンポーネントを使用する 2 つの API の結果を集約する場合、デフォルトでは API 1 と API 2 のエラーが同じため、API ごとに区別したいことがあります。 マッピングにより、エラーを適切なエラーハンドラーにルーティングすることでエラー処理をカスタマイズできます。次の例では、最初の Request 操作からエラーハンドラー ​`APP:API_1`​ にエラーをルーティングし、2 つ目の Request 操作から ​`APP:API_2`​ にエラーをルーティングしています。この例では、API がダウンしたときに異なる処理ポリシーを適用するために ​`HTTP:INTERNAL_SERVER_ERROR`​ を各エラーハンドラーにマッピングしています。片方のマッピングは、最初の API から来たエラーを伝播します。他方のマッピングは、2 つ目の API から来たエラーを処理します。 ![HTTP 内部サーバーエラーのエラーマッピング設定が表示されている設定パネル](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/error-handling-mappings.png) ## [](#関連情報)関連情報 - [エラーハンドラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/error-handling) - [Mule エラー](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-error-concept) - [On-Error コンポーネント](https://docs.mulesoft.com/jp/mule-runtime/4.7/on-error-scope-concept) - [Try スコープ](https://docs.mulesoft.com/jp/mule-runtime/4.7/try-scope-concept)