Tại sao dấu ngoặc được yêu cầu để thử bắt?

Trong các ngôn ngữ khác nhau (ít nhất là Java, cũng nghĩ là C #?) Bạn có thể làm những việc như

if( condition )
    singleStatement;

while( condition )
    singleStatement;

for( var; condition; increment )
    singleStatement;

Vì vậy, khi tôi chỉ có một tuyên bố, tôi không cần thêm phạm vi mới { }. Tại sao tôi không thể làm điều này với thử bắt?

try
    singleStatement;
catch(Exception e)
    singleStatement;

Có điều gì đặc biệt về thử bắt đòi hỏi phải luôn có phạm vi mới hoặc thứ gì đó không? Và nếu vậy, trình biên dịch có thể sửa nó không?

IMO, chúng được bao gồm trong Java và C # chủ yếu vì chúng đã tồn tại trong C ++. Câu hỏi thực sự là tại sao C ++ lại như vậy. Theo Thiết kế và tiến hóa của C ++ (§16.3):

Các trytừ khóa là hoàn toàn không cần thiết và như vậy là { }dấu ngoặc trừ trường hợp nhiều câu lệnh đang thực sự được sử dụng trong một thử khối hoặc một handler. Ví dụ, việc cho phép:

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

Tuy nhiên, tôi thấy điều này rất khó để giải thích rằng sự dư thừa đã được đưa ra để cứu nhân viên hỗ trợ khỏi những người dùng bối rối.

Chỉnh sửa: Về lý do tại sao điều này sẽ gây nhầm lẫn, tôi nghĩ rằng người ta chỉ cần nhìn vào các xác nhận không chính xác trong câu trả lời của @Tom Jeffery (và đặc biệt là số lượng phiếu bầu đã nhận được) để nhận ra rằng sẽ có vấn đề. Đối với trình phân tích cú pháp, điều này thực sự không khác gì so với khớp elses với ifthiếu niềng răng để buộc các nhóm khác, tất cả catch các mệnh đề sẽ khớp với gần đây nhất throw. Đối với những kẻ lạc lõng bao gồm nó, finallycác mệnh đề cũng sẽ làm như vậy. Từ quan điểm của trình phân tích cú pháp, điều này hầu như không đủ khác biệt với tình huống hiện tại cần chú ý - đặc biệt, vì các ngữ pháp hiện nay, thực sự không có gì để nhóm các catchmệnh đề lại với nhau - các dấu ngoặc đơn nhóm các câu lệnh được điều khiển bởicatch mệnh đề, không phải là mệnh đề bắt chính chúng.

Từ quan điểm viết một trình phân tích cú pháp, sự khác biệt gần như quá nhỏ để nhận thấy. Nếu chúng ta bắt đầu với một cái gì đó như thế này:

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

statement: compound_statement
         | simple_statement
         ;

statements: 
          | statements statement
          ;

compound_statement: '{' statements '}'

catch_arg: '(' argument ')'

Sau đó, sự khác biệt sẽ là giữa:

try_clause: 'try' statement

và:

try_clause: 'try' compound_statement

Tương tự như vậy, đối với các mệnh đề bắt:

catch_clause: 'catch' catch_arg statement

so với

catch_clause: 'catch' catch_arg compound_statement

Định nghĩa của một khối thử / bắt hoàn chỉnh hoàn toàn không cần phải thay đổi. Dù bằng cách nào, nó sẽ là một cái gì đó như:

catch_clauses: 
             | catch_clauses catch_clause
             ;

try_block: try_clause catch_clauses [finally_clause]
         ;

[Ở đây tôi đang sử dụng [whatever]để chỉ ra một cái gì đó tùy chọn và tôi bỏ qua cú pháp finally_clausevì tôi không nghĩ nó có liên quan gì đến câu hỏi.]

Ngay cả khi bạn không cố gắng tuân theo tất cả các định nghĩa ngữ pháp giống như Yacc ở đó, điểm có thể được tóm tắt khá dễ dàng: câu lệnh cuối cùng (bắt đầu bằng try_block) là catchmệnh đề khớp với trymệnh đề - và nó vẫn chính xác là giống nhau cho dù niềng răng có cần thiết hay không.

Để nhắc lại / tóm tắt: các dấu ngoặc nhóm lại với nhau những điều khoản kiểm soát bởi các catchs, nhưng làm không nhóm catchlà bản thân họ. Như vậy, những cái niềng răng đó hoàn toàn không có tác dụng gì khi quyết định cái nào catchđi với cái nào try. Đối với trình phân tích cú pháp / trình biên dịch, tác vụ cũng dễ dàng (hoặc khó) như nhau. Mặc dù vậy, câu trả lời của @ Tom (và số lượng phiếu bầu tăng lên mà nó nhận được) cung cấp bằng chứng rộng rãi về thực tế rằng một sự thay đổi như vậy gần như chắc chắn sẽ gây nhầm lẫn cho người dùng.

Trong một câu trả lời về lý do tại sao các dấu ngoặc được yêu cầu cho một số cấu trúc câu lệnh đơn nhưng không phải là các câu lệnh khác , Eric Lippert đã viết:

Có một số nơi mà C # yêu cầu một khối các câu lệnh thay vì cho phép một câu lệnh "trần trụi". Họ đang:

• phần thân của một phương thức, hàm tạo, hàm hủy, hàm truy cập thuộc tính, hàm truy cập sự kiện hoặc hàm truy cập chỉ mục.
• khối của một vùng thử, bắt, cuối cùng, được kiểm tra, không được kiểm tra hoặc không an toàn.
• khối của một tuyên bố lambda hoặc phương thức ẩn danh
• khối của một câu lệnh if hoặc loop nếu khối trực tiếp chứa một khai báo biến cục bộ. (Nghĩa là "while (x! = 10) int y = 123;" là bất hợp pháp; bạn phải thực hiện khai báo.)

Trong mỗi trường hợp này, có thể đưa ra một ngữ pháp không rõ ràng (hoặc heuristic để phân biệt một ngữ pháp mơ hồ) cho tính năng trong đó một tuyên bố không phân biệt là hợp pháp. Nhưng vấn đề sẽ là gì? Trong mỗi tình huống bạn đang mong đợi để xem nhiều câu lệnh; tuyên bố duy nhất là trường hợp hiếm, không có khả năng. Có vẻ như nó không thực sự xứng đáng để làm cho ngữ pháp không rõ ràng cho những trường hợp rất khó xảy ra này.

Nói cách khác, chi phí cao hơn cho nhóm biên dịch để thực hiện nó hơn là hợp lý, vì lợi ích cận biên mà nó sẽ cung cấp.

Tôi nghĩ rằng đó là để tránh các vấn đề phong cách khác. Sau đây sẽ là mơ hồ ...

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?

Nó có thể có nghĩa này:

try {
   try {

   } catch(Exception e1) {

   } catch(Exception e2) {

   } 
} finally {

} 

Hoặc là...

try {
   try {

   } catch(Exception e1) {

   } 
} catch(Exception e2) {

} finally {

} 

Tôi nghĩ lý do chính là có rất ít bạn có thể làm trong C # mà sẽ cần một khối thử / bắt chỉ có một dòng. (Tôi không thể nghĩ về bất kỳ ngay bây giờ trên đỉnh đầu của tôi). Bạn có thể có một điểm hợp lệ về mặt khối bắt, ví dụ: một câu lệnh một dòng để ghi nhật ký một cái gì đó nhưng về khả năng đọc thì nó có ý nghĩa hơn (ít nhất là với tôi) để yêu cầu {}.