<try> 手順は、手順ブロックの典型的なエラー処理とクリーンアップロジックを指定するために使用されます。 この手順に属性はなく、子は <block>、<catch>、および <finally> 要素から構成されます。
<try> 手順は次のように実行されます。
<block> 要素内の手順は、すべてが完了するか (Plan Executor の各手順に関する エラー定義に従って) 手順のどれかが失敗するまで順に実行されます。
<catch> 要素が定義されており、かつプランの中断 (abort) またはプランのタイムアウト以外の手順エラーでブロック要素の実行が終了した場合にかぎって、すべてが完了するかあるいは手順のどれかが失敗するまで <catch> 要素内の手順が順に実行されます。
<finally> 要素が定義されている場合、その手順はそれらがすべてが完了するか手順のどれかが失敗するまで順に実行されます。 これは、プランの中断またはプランのタイムアウトのために先の 2 つの要素のどちらか一方が停止しないかぎり、それらの要素の成否に関係なく発生します。
上記の規則があることから、プランの中断またはプラン (手順ではなく) のタイムアウトのために包含される手順のどれかが失敗する場合、包含されるほかの手順は実行されず、<try> 手順の実行はエラーを示して終了します。
<catch> 要素は、<block> 要素内で発生するエラーの抑制と、これらのエラーからの回復のために使用されます。 <finally> 要素は、典型的なエラーが検出されるかどうかにかかわらず、無条件でクリーンアップを行うために使用されます。
<try> 手順は、以下のように成否が決まります。
<try> 手順に <finally> 要素だけが含まれる場合 (<catch> は含まれない)、<block> または <finally> 要素の実行が失敗するとこの手順は失敗します。
<try> 手順に <catch> 要素だけが含まれる場合 (<finally> は含まれない)、この手順は以下の状況のどちらか一方が発生するときだけ失敗します。
<catch> 要素の実行が行われて失敗した
プランの中断またはプランのタイムアウトのために <block> 要素が失敗した
<try> 手順に <catch> および <finally> 要素の両方が含まれる場合、この手順は以下の状況のいずれかが発生するときだけ失敗します。
<catch> または <finally> 要素が実行されて失敗した
<finally> 要素が実行されて失敗した
プランの中断またはプランのタイムアウトのために <block> 要素が失敗した
以上のことから、<block> 要素の失敗は <catch> 要素の存在で抑制できると言えます。
名前 |
数 |
説明 |
---|---|---|
block |
1 |
初めに実行される手順 |
catch |
0 または 1 |
典型的なエラー時に実行される手順。 finally が指定されない場合に指定する必要がある |
finally |
0 または 1 |
典型的なエラーであるかどうかにかかわらず実行される手順。 catch が指定されない場合に指定する必要がある |
インストールにおいてリソースの配備と再起動を行う必要があるコンポーネントがある場合を考えてみます。 このケースでは、コンポーネントのインストールが完了したと見なされるのは、そのリソースが配備され、再起動時におけるエラーがそのインストール状態に影響を与えない場合だけです。 典型的なエラーは、以下のように再起動時に抑制できます。
<installSteps blockName="default"> <deployResource/> <try> <block> <call blockName="restart"><thisComponent/></call> </block> <catch/><!-- suppress all typical errors --> </try> </installSteps> |
try ブロックは、インテリジェントな自動アップグレードをモデル化するためにも使用できます。 バージョン 1.1 のコンポーネントが存在し、バージョン 1.0 を以前にインストールしたことがあるかどうかに基づいて選択できる 2 つの異なるインストールルーチン、フレッシュインストールとアップグレードインストールが存在する場合を考えてみます。 このケースは、以下のように単一のインストールブロックとしてモデル化できます。
<installSteps blockName="default"> <try> <block> <checkDependency> <installedComponent name="foo" version="1.0"/> </checkDependency> <!-- 1.0 install exists, do upgrade --> </block> <catch> <!-- 1.0 install doesn"t exist, do fresh install --> </catch> </try> </installSteps> |
<finally> ブロックは、通常、一時リソースのクリーンアップに使用されます。 次の例では、一時ファイルの作成、処理、および削除が行われます。
<control blockName="default"> <varList> <var name="file" default="/tmp/file.txt"/> </varList> <execNative outputFile=":[file]"> <exec cmd="ls"><arg value="-l"/></exec> </execNative> <try> <block> <!-- process file in some way --> </block> <finally> <execNative> <exec cmd="rm"><arg value=":[file]"/></exec> </execNative> </finally> </try> </control> |
<block> 要素は <try> 手順の子要素であり、<try> 手順によって実行される主要な手順を指定します。 この要素には、<try> 手順を含んでいるブロックのスコープ内で許可される 1 つ以上の手順が含まれます。
<catch> 要素は <try> 手順の子要素であり、<block> 要素の手順を実行している際に典型的なエラーが発生する場合に実行する手順を指定します。 この要素には、<try> 手順を含んでいるブロックのスコープ内で許可される任意の数の手順を含めることができます。
<catch> 要素には、<block> 要素の典型的なエラーを抑制するという機能と、典型的なエラー回復作業を定義するという機能があります。 この要素は空にすることができます。空にすると、この要素は典型的なエラーの抑制だけを行います。
<try> 手順の子要素であり、<try> または <catch> 手順内で典型的なエラーが以前に発生したかどうかにかかわらず実行する手順を指定します。典型的なエラーには、プランの中断とプランのタイムアウトがあります (これらのエラーが発生した場合、<finally> 要素の手順はすべてまとめてスキップされる)。 この要素には、<try> 手順を含んでいるブロックのスコープ内で許可される任意の数の手順を含めることができます。
<finally> 要素は、ほかの典型的なエラー状況を考慮することなくクリーンアップを開始する必要がある場合に、主にリソースのクリーンアップと解放を行う手順を指定する目的で使用されます。