try-catchにブラケットが必要なのはなぜですか？

さまざまな言語（少なくともJava、C＃も考えますか）では、次のようなことができます

if( condition )
    singleStatement;

while( condition )
    singleStatement;

for( var; condition; increment )
    singleStatement;

したがって、ステートメントが1つしかない場合、を使用して新しいスコープを追加する必要はありません{ }。try-catchでこれができないのはなぜですか？

try
    singleStatement;
catch(Exception e)
    singleStatement;

常に新しいスコープなどを必要とするtry-catchについて特別なものはありますか？もしそうなら、コンパイラはそれを修正できませんでしたか？

IMO、これらは主にC ++にすでに存在するため、JavaおよびC＃に含まれています。本当の問題は、C ++がなぜそうなのかということです。よるCの設計と進化++（§16.3）：

このtryキーワードは完全に冗長であるため{ }、複数のステートメントがtryブロックまたはハンドラーで実際に使用される場合を除き、括弧も完全に冗長です。たとえば、以下を許可するのは簡単なことです。

int f()
{
    return g() catch(xxii) { // not C++
        error("G() goofed: xxii");
        return 22;
    };
}

しかし、サポート担当者を混乱したユーザーから守るために冗長性が導入されたことを説明するのは非常に難しいと感じました。

編集：なぜこれが混乱するかについては、問題があることを認識するために、@ Tom Jefferyの答え（および特に、それが受け取ったアップ投票の数）の誤った主張を見るだけでよいと思います。パーサーにとって、これはelsesとifsのマッチングと実際には違いはありません。他のグループ化を強制する中括弧がなく、すべての catch句が最新のに一致しthrowます。それを含む誤って誤解された言語については、finally条項も同じことをします。パーサーの観点から見ると、これは現在の状況と気づくのに十分な違いはありません-特に、現在の文法では、catch句をグループ化することは本当にありません-括弧は、catch catch句ではなく句。

パーサーを書くという観点から見ると、その差はほとんど気付かないほどです。このようなものから始める場合：

simple_statement: /* won't try to cover all of this */
                ;

statement: compound_statement
         | simple_statement
         ;

statements: 
          | statements statement
          ;

compound_statement: '{' statements '}'

catch_arg: '(' argument ')'

次に、違いは次のようになります。

try_clause: 'try' statement

そして：

try_clause: 'try' compound_statement

同様に、catch句の場合：

catch_clause: 'catch' catch_arg statement

対

catch_clause: 'catch' catch_arg compound_statement

ただし、完全なtry / catchブロックの定義を変更する必要はまったくありません。いずれにしても、それは次のようなものになります。

catch_clauses: 
             | catch_clauses catch_clause
             ;

try_block: try_clause catch_clauses [finally_clause]
         ;

[ここでは[whatever]、オプションの何かを示すために使用していますが、aの構文は省略しています。finally_clauseなぜなら、それが問題に関係しているとは思わないからです。]

そこにあるYaccのような文法の定義すべてに従おうとしない場合でも、ポイントはかなり簡単に要約できます：最後のステートメント（で始まるtry_block）は、catch句が句と一致するものでtryあり、正確にそのままです中かっこが必要かどうかに関係なく同じです。

繰り返し/要約する：中括弧は、s によって制御されるステートメントをグループ化しますcatchが、s自体はグループ化しませんcatch。そのため、これらの中括弧は、どちらがどちらを使用するかを決定する際にまったく効果がありません。パーサー/コンパイラの場合、タスクはどちらの方法でも同様に簡単（または難しい）です。それにも関わらず、@ Tomの回答（および受け取った賛成票の数）は、そのような変更がユーザーを混乱させることはほぼ確実であるという事実の十分な実証を提供します。catchtry

でブラケットがいくつかの単一の文の構造ではなく、他人のために必要とされる理由について答え、エリックリペットは書きました：

「裸の」ステートメントを許可するのではなく、C＃でステートメントのブレースブロックを必要とする場所がいくつかあります。彼らです：

• メソッド、コンストラクタ、デストラクタ、プロパティアクセサ、イベントアクセサ、またはインデクサアクセサの本体。
• try、catch、finally、checked、unchecked、またはunsafe領域のブロック。
• ステートメントラムダまたは匿名メソッドのブロック
• ブロックにローカル変数宣言が直接含まれている場合のifまたはloopステートメントのブロック。（つまり、「while（x！= 10）int y = 123;」は不正です。宣言を中括弧で囲む必要があります。）

これらの各ケースでは、単一の括弧なしステートメントが合法である機能に対して、明確な文法（または曖昧な文法を明確にするための発見的手法）を考え出すことができます。しかし、ポイントは何でしょうか？これらの状況のそれぞれで、複数のステートメントが表示されることを期待しています。単一のステートメントはまれであり、まれなケースです。これらの非常にありそうもないケースのために文法を曖昧にすることは本当に価値がないように思われます。

言い換えれば、コンパイラーチームが実装するのは、それが提供するわずかな利点のために正当化されるよりも高価でした。

他のスタイルの問題を回避するためだと思います。次はあいまいです...

try
    // Do stuff
try
    // Do  more stuff
catch(MyException1 e1)
    // Handle fist exception
catch(MyException2 e2)
    // So which try does this catch belong to?
finally
    // and who does this finally block belong to?

これは次のことを意味します。

try {
   try {

   } catch(Exception e1) {

   } catch(Exception e2) {

   } 
} finally {

} 

または...

try {
   try {

   } catch(Exception e1) {

   } 
} catch(Exception e2) {

} finally {

} 

主な理由は、1行だけのtry / catchブロックを必要とするC＃でできることはほとんどないためだと思います。（頭のてっぺんのことは今は考えられません）。catchブロックに関しては有効なポイントがあります。たとえば、何かを記録する1行のステートメントですが、読みやすさの観点からは（少なくとも私にとって）{}を要求する方が理にかなっています。