Mengapa tanda kurung diperlukan untuk coba-tangkap?

Dalam berbagai bahasa (setidaknya Java, pikirkan juga C #?) Anda dapat melakukan hal-hal seperti

if( condition )
    singleStatement;

while( condition )
    singleStatement;

for( var; condition; increment )
    singleStatement;

Jadi, ketika saya hanya memiliki satu pernyataan, saya tidak perlu menambahkan cakupan baru dengan { }. Mengapa saya tidak bisa melakukan ini dengan try-catch?

try
    singleStatement;
catch(Exception e)
    singleStatement;

Apakah ada sesuatu yang istimewa tentang try-catch yang mengharuskan selalu memiliki ruang lingkup baru atau sesuatu? Dan jika demikian, bukankah kompiler dapat memperbaikinya?

IMO, mereka termasuk dalam Java dan C # terutama karena mereka sudah ada di C ++. Pertanyaan sebenarnya adalah mengapa C ++ seperti itu. Menurut Desain dan Evolusi C ++ (§16.3):

Kata trykunci benar-benar berlebihan dan begitu pula { }tanda kurung kecuali di mana banyak pernyataan benar-benar digunakan dalam blok-coba atau penangan. Misalnya, sepele untuk mengizinkan:

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

Namun, saya menemukan ini sangat sulit untuk menjelaskan bahwa redundansi diperkenalkan untuk menyelamatkan personil pendukung dari pengguna yang bingung.

Sunting: Mengenai mengapa ini akan membingungkan, saya pikir kita hanya perlu melihat pernyataan yang salah dalam jawaban @Tom Jeffery (dan, terutama, jumlah suara yang diterima) untuk menyadari bahwa akan ada masalah. Bagi parser, ini benar-benar tidak berbeda dari mencocokkan elsedengan ifs - kurang kawat gigi untuk memaksa pengelompokan lain, semua catch klausa akan cocok dengan yang terbaru throw. Untuk bahasa-bahasa yang salah yang memasukkannya, finallyklausa akan melakukan hal yang sama. Dari sudut pandang parser, ini hampir tidak cukup berbeda dari situasi saat ini untuk diperhatikan - khususnya, karena tata bahasa berdiri sekarang, benar-benar tidak ada yang mengelompokkan catchklausa bersama - kurung mengelompokkan pernyataan yang dikendalikan olehcatch klausa, bukan tangkapan klausa sendiri.

Dari sudut pandang menulis parser, perbedaannya hampir terlalu kecil untuk diperhatikan. Jika kita mulai dengan sesuatu seperti ini:

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

statement: compound_statement
         | simple_statement
         ;

statements: 
          | statements statement
          ;

compound_statement: '{' statements '}'

catch_arg: '(' argument ')'

Maka perbedaannya adalah antara:

try_clause: 'try' statement

dan:

try_clause: 'try' compound_statement

Demikian juga, untuk klausa tangkap:

catch_clause: 'catch' catch_arg statement

vs.

catch_clause: 'catch' catch_arg compound_statement

Definisi blok coba / tangkap lengkap tidak perlu diubah sama sekali. Bagaimanapun itu akan menjadi seperti:

catch_clauses: 
             | catch_clauses catch_clause
             ;

try_block: try_clause catch_clauses [finally_clause]
         ;

[Di sini saya menggunakan [whatever]untuk menunjukkan sesuatu yang opsional, dan saya meninggalkan sintaks untuk finally_clausekarena saya tidak berpikir ada kaitannya dengan pertanyaan.]

Bahkan jika Anda tidak mencoba mengikuti semua definisi tata bahasa seperti Yacc di sana, intinya dapat diringkas dengan cukup mudah: bahwa pernyataan terakhir (dimulai dengan try_block) adalah pernyataan di mana catchklausa dicocokkan dengan tryklausa - dan tetap persis seperti itu. sama apakah kawat gigi diperlukan atau tidak.

Untuk mengulangi / meringkas: kelompok kawat gigi bersama-sama laporan dikendalikan oleh para catchs, tapi lakukan tidak kelompok catchs sendiri. Dengan demikian, kawat gigi itu sama sekali tidak berpengaruh pada memutuskan mana catchyang sesuai try. Untuk parser / kompiler, tugasnya sama mudah (atau sulit). Meskipun demikian, jawaban @ Tom (dan jumlah suara yang diterima) memberikan banyak bukti bahwa perubahan semacam itu hampir pasti akan membingungkan pengguna.

Dalam sebuah jawaban tentang mengapa tanda kurung diperlukan untuk beberapa konstruksi pernyataan tunggal tetapi tidak yang lain , Eric Lippert menulis:

Ada sejumlah tempat di mana C # membutuhkan blok pernyataan yang kuat daripada membiarkan pernyataan "telanjang". Mereka:

• badan metode, konstruktor, destruktor, pengakses properti, pengakses acara atau pengindeks pengindeks.
• blok daerah coba, tangkap, akhirnya, dicentang, tidak dicentang atau tidak aman.
• blok pernyataan lambda atau metode anonim
• blok pernyataan jika atau loop jika blok secara langsung berisi deklarasi variabel lokal. (Yaitu, "sementara (x! = 10) int y = 123;" adalah ilegal; Anda harus menguatkan deklarasi.)

Dalam masing-masing kasus ini adalah mungkin untuk menghasilkan tata bahasa yang tidak ambigu (atau heuristik untuk mengaburkan tata bahasa yang ambigu) untuk fitur di mana satu pernyataan yang tidak diikat adalah sah. Tapi apa gunanya? Dalam setiap situasi itu Anda mengharapkan untuk melihat banyak pernyataan; pernyataan tunggal adalah kasus yang jarang, tidak mungkin. Sepertinya tidak layak untuk membuat tata bahasa tidak ambigu untuk kasus-kasus yang sangat tidak mungkin ini.

Dengan kata lain, itu lebih mahal bagi tim penyusun untuk mengimplementasikannya daripada dibenarkan, untuk manfaat marjinal yang diberikannya.

Saya pikir itu untuk menghindari masalah gaya lain. Berikut ini akan menjadi ambigu ...

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?

Ini bisa berarti ini:

try {
   try {

   } catch(Exception e1) {

   } catch(Exception e2) {

   } 
} finally {

} 

Atau...

try {
   try {

   } catch(Exception e1) {

   } 
} catch(Exception e2) {

} finally {

} 

Saya pikir alasan utama adalah bahwa ada sangat sedikit yang dapat Anda lakukan di C # yang akan memerlukan blok coba / tangkap yang hanya satu baris. (Saya tidak bisa memikirkan apa pun sekarang dari atas kepala saya). Anda mungkin memiliki titik valid dalam hal blok tangkap, misalnya pernyataan satu baris untuk mencatat sesuatu tetapi dalam hal keterbacaan, lebih masuk akal (setidaknya bagi saya) untuk meminta {}.