禁忌かというと、まず一点は、スパゲッティコードになるから。使う構文なので、それはまあ仕方ありません。いう機能があるからです。エラーが起きた場所から処理をやり直すという意味の命令です。エラーが起きても、元の正常処理を続きから再開できるというとても強力で忌々しい命令です。確かに、使ってもさほど影響がない部分というのはもちろんありますが、闇雲に多用してしまうとあとからどうしようもないコードが生まれてしまうので、現在では意図的に避けられています。詳しい説明はここでは省きますので、上記のコードがどのように動作するかを簡単にまとめます。出力結果A通りますよーB通りますよーErrProc2でっせ5:プロシージャの呼び出し、または引数が不正です。対して、もっとオブジェクトな指向の例外処理があります。名の通り、文法の構造的に例外処理が保証される仕組みです。時代には存在しませんでした。あらゆる言語に同様の構文が定義されており、非常に扱いやすい構文だと思います。Module構造化するということは、つまりブロックをネストするという意味ですので、先程のコードよりかなりインデントが深くなっています。機能に該当する機能は一切ないですし、任意に例外処理の実行順を入れ替えることもできません。できることが制限されたように思いますが、この制限があるからこそ、スパゲッティコードが生まれにくいという恩恵をうけることができます。出力結果A通りますよーB通りますよーErrProc2でっせプロシージャの呼び出し、または引数が不正です。出力結果A通りますよーB通りますよーC通りますよーErrProc3でっせErrProc2でっせプロシージャの呼び出し、または引数が不正です。出力結果A通りますよーB通りますよーC通りますよーD通りますよーErrProc3でっせErrProc2でっせプロシージャの呼び出し、または引数が不正です。おわり※なお、ケース2,3,4中のエラーメッセージは、例外の種類で異なります。構造化例外処理と非構造化例外処理の共存これら2つの文法は、お互いに排他的に使わなければなりません。厳密には、同じプロシージャ内、いわば一つのメソッド内に両方記述してはならないという言語仕様になっています。書いた時点でコンパイルエラーになります。最近まで、私はこれ以外の構造化例外処理を知りませんでした。次の記事では、もう一つ、構造化例外処理を利用したコードを紹介しています。code.msdn.microsoft.com少々古めの記事ですが、読んでみましょう。私は自分の目を疑いましたよ。いう便利な構文があります。インターフェイスを実装したクラスのインスタンスに対し、構文上でその破棄を保証するものです。句へ変貌するというのです。いうステートメントがありますが、このリファレンスには次のような説明がされています。呼び出しても、同じ結果が得られます。ステートメントをこのように変換します。(オブジェクトのスコープの範囲を定義する中かっこが加えられています)。必然的に同じような動作になるのでしょうね。構造化例外処理の仲間となっていまいます。