「At...」 でのステップ リファレンス
エラー処理では、エラーが発生したときに実行を続行するさまざまな方法を選択することができます。以下に挙げる 3 つの方法では、実行を再開する場所となる実行パス上の前のステップ (トライ ステップまたは繰り返しステップのどちらか) を特定する必要があります。ユーザーによる以下の選択に応じて、実行は、選択されたステップまたは選択されたステップの後から続行されます。
- 次のトライステップへ移動
- 次のイテレーションへ移動
- ループ終了
優先ステップを特定するときは、(適切な種類の)「最も近いステップ」を選択するか、名前で特定のステップを選択することができます。ただし、さまざまな理由により、優先ステップが選択リストに表示されないこともあります。
- 名前付きステップのみを選択できます。ステップに名前がない場合 (トライ ステップのデフォルト)、ステップを選択リストに表示するには、ステップに名前を付ける必要があります。ステップが適切な種類の最も近いステップである場合は、「最も近いステップ」を選択することによってそのステップにアクセスすることもできます。
- [次のイテレーションへ移動] を [繰り返し] ステップと組み合わせて使用することはできないことに注意してください。したがって、[繰り返し] ステップは [次のイテレーションへ移動] の選択リストに表示されません。
- 特定先は必ず選択された名前を持つ (適切な種類の) 最も近いステップになるため、ステップ名が選択リストに複数回表示されることは決してありません。ロボットを変更するときはこのことを念頭に置いてください!
- ロボットを通って現在のステップに至るパスが複数ある場合は、選択された名前を持つ (適切な) ステップが現在のステップに至るすべてのパス上に存在する必要があります。存在しない場合、名前は選択リストに表示されません。
最後の 2 つの規則は Java または C# の トライ-キャッチ 構造体に非常によく似た高度な方法によるエラー処理の使用をサポートしています。このトピックの詳細については、トライ-キャッチ セクションを参照してください。これらのプログラミング言語では、エラー発生点で名前付き「例外」を「スロー」し、周囲のコードのどこかで (名前で) それを「キャッチ」します。ロボットでは、トライ ステップで似たような処理を実行できます。Java または C# の用語と Design Studio の用語の対応を以下の表に示します。
Java/C# の用語 | Design Studio で使用するもの |
---|---|
トライ |
トライ ステップの最初の分岐 |
例外の名前 |
トライ ステップの名前 |
throw E |
E における [次のトライステップへ移動] によるエラー処理 |
catch E |
名前 "E" を持つトライ ステップの 2 番目の分岐 |
エラー処理に対するこの考え方は、おそらく大規模なロボットで最も有用でしょう。この方法でエラー処理を使用する場合、トライ ステップの名前は、個々のトライ ステップの 2 番目の分岐が処理する例外状況の種類を示します。