Tại sao Try-Catch yêu cầu dấu ngoặc nhọn

Question

Chỉ cần tò mò: Tại sao cú pháp cho try catch in C# (Java cũng?) Được mã hóa cứng cho nhiều câu lệnh? Tại sao ngôn ngữ không cho phép:

int i; 
string s = DateTime.Now.Seconds % 2 == 1 ? "1" : "not 1"; 
try 
    i = int.Parse(s); 
catch 
    i = 0; 

Ví dụ này chỉ dành cho mục đích tầm thường. Tôi biết có int.TryParse.

Answer 1

xem xét thực tế rằng có thực sự ba (hoặc nhiều hơn) khối mã các học trò ở đây:

try {} 
catch (myexcption) 
{} 
catch (myotherexception) 
{} 
finally 
{} 

Hãy nhớ rằng những điều này nằm trong phạm vi của một ngữ cảnh lớn hơn và các trường hợp ngoại lệ không bị bắt được đẩy mạnh hơn nữa lên ngăn xếp.

Lưu ý rằng điều này về cơ bản giống với cấu trúc lớp học cũng có cấu trúc {}.

Nói ví dụ bạn có thể có:

try 
try 
if (iAmnotsane) 
beatMe(please); 
catch (Exception myexception) 
catch (myotherexception) 
logerror("howdy") 
finally 

VỚI DOANH NGHIỆP nào đó bắt thứ hai thuộc về người đầu tiên hoặc thứ hai thử? Còn cuối cùng thì sao? SO bạn thấy các phần tùy chọn/nhiều làm cho yêu cầu.

Answer 2

Các hợp lý là nó dễ bảo trì hơn (dễ dàng hơn để thay đổi, ít có khả năng để phá vỡ, ergo chất lượng cao hơn):

1. nó rõ ràng hơn, và
2. nó dễ dàng hơn để thay đổi bởi vì nếu bạn cần phải thêm một đường vào các khối của bạn, bạn không giới thiệu một lỗi.

Là tại sao xử lý ngoại lệ khác với biểu thức có điều kiện ...

• Nếu/khác có điều kiện thuận một biểu thức để sử dụng một trong hai (hoặc nhiều hơn Nếu/Else if/else) đường dẫn trong mã số
• Thử/Catch là một phần của xử lý ngoại lệ, nó không phải là biểu thức có điều kiện. Try/Catch/Cuối cùng chỉ hoạt động khi một ngoại lệ đã được ném vào bên trong phạm vi của khối Thử.

Xử lý ngoại lệ sẽ di chuyển lên chồng/phạm vi cho đến khi tìm thấy khối Bắt giữ sẽ loại ngoại lệ được ném. Việc buộc các số nhận dạng phạm vi làm cho việc kiểm tra các khối này được đơn giản hóa. Buộc bạn phạm vi khi đối phó với các ngoại lệ có vẻ như là một ý tưởng hay, nó cũng là một dấu hiệu tốt cho thấy đây là một phần của xử lý ngoại lệ chứ không phải là mã bình thường. Ngoại lệ là ngoại lệ, không phải là điều bạn thực sự muốn xảy ra bình thường nhưng biết có thể xảy ra và muốn xử lý khi chúng xảy ra.

EDIT: Có một lý do nữa mà tôi có thể nghĩ đến, đó là CATCH là bắt buộc sau TRY không giống như ELSE. Do đó cần phải có cách xác định để xác định khối TRY.

Answer 3

Có lẽ là không khuyến khích lạm dụng. Một khối try-catch là lớn và xấu xí, và bạn sẽ nhận thấy khi bạn đang sử dụng nó. Điều này phản ánh ảnh hưởng của việc nắm bắt hiệu suất ứng dụng của bạn - bắt một ngoại lệ cực kỳ chậm so với một thử nghiệm boolean đơn giản.

Nói chung, bạn nên tránh lỗi, không xử lý chúng. Trong ví dụ bạn đưa ra, một phương pháp hiệu quả hơn sẽ là sử dụng

if(!int.TryParse(s, out i)) 
i=0; 

Answer 4

Điều đầu tiên tôi nghĩ là các dấu ngoặc nhọn tạo ra một khối với phạm vi biến riêng của nó.

Nhìn vào đoạn mã sau

try 
{ 
    int foo = 2; 
} 
catch (Exception) 
{ 
    Console.WriteLine(foo); // The name 'foo' does not exist in the current context 
} 

foo không thể truy cập trong khối catch do Phạm vi biến. Tôi nghĩ rằng điều này làm cho nó dễ dàng hơn để lý do về việc liệu một biến đã được khởi tạo trước khi sử dụng hay không.

Hãy so sánh với mã này

int foo; 
try 
{ 
    foo = 2; 
} 
catch (Exception) 
{ 
    Console.WriteLine(foo); // Use of unassigned local variable 'foo' 
} 

đây bạn không thể đảm bảo rằng foo được khởi tạo.

Answer 5

Câu trả lời đơn giản nhất (tôi nghĩ) là mỗi khối mã trong C/C++/C# yêu cầu dấu ngoặc nhọn.

EDIT # 1

Để đối phó với phiếu chống, trực tiếp từ MSDN:

try-catch (C# Reference)

Các câu lệnh try-catch bao gồm một thử khối theo sau là một hoặc nhiều mệnh đề bắt, chỉ định các trình xử lý cho các ngoại lệ khác nhau.

Theo định nghĩa, đó là một khối, do đó, nó yêu cầu dấu ngoặc nhọn. Đó là lý do tại sao chúng tôi không thể sử dụng nó mà không có { }.

Answer 6

try // 1 
try // 2 
    something(); 
catch { // A 
} 
catch { // B 
} 
catch { // C 
} 

B bắt thử 1 hoặc 2?

Tôi không nghĩ rằng bạn có thể giải quyết này một cách rõ ràng, kể từ đoạn có thể có nghĩa:

try // 1 
{ 
    try // 2 
     something(); 
    catch { // A 
    } 
} 
catch { // B 
} 
catch { // C 
} 


try // 1 
{ 
    try // 2 
     something(); 
    catch { // A 
    } 
    catch { // B 
    } 
} 
catch { // C 
} 

Answer 7

CẬP NHẬT: Câu hỏi này là chủ đề của my blog on December 4th, 2012. Có một số nhận xét sâu sắc trên blog mà bạn cũng có thể quan tâm. Cảm ơn câu hỏi tuyệt vời!

---

Như những người khác đã lưu ý, tính năng được đề xuất giới thiệu sự mơ hồ gây nhầm lẫn. Tôi đã quan tâm để xem liệu có bất kỳ biện minh nào khác cho quyết định không hỗ trợ tính năng này hay không, vì vậy tôi đã kiểm tra lưu trữ ghi chú thiết kế ngôn ngữ.

Tôi không thấy gì trong lưu trữ ghi chú thiết kế ngôn ngữ để biện minh cho quyết định này. Theo như tôi biết, C# thực hiện nó theo cách đó bởi vì đó là cách các ngôn ngữ khác có cú pháp tương tự thực hiện nó, và họ làm theo cách đó vì vấn đề mơ hồ.

Tôi đã học được điều gì đó thú vị. Trong thiết kế ban đầu của C# không có cố gắng-bắt-cuối cùng!Nếu bạn muốn thử với câu trả lời và cuối cùng thì bạn phải viết:

try 
{ 
    try 
    { 
     XYZ(); 
    } 
    catch(whatever) 
    { 
    DEF(); 
    } 
} 
finally 
{ 
    ABC(); 
} 

mà, không ngạc nhiên, chính xác là cách trình biên dịch phân tích cố gắng nắm bắt cuối cùng; nó chỉ phá vỡ nó vào cố gắng nắm bắt bên trong cố gắng cuối cùng khi phân tích ban đầu và giả vờ đó là những gì bạn đã nói ở nơi đầu tiên.

Answer 8

Ít hoặc nhiều, đây là lần phát trên dangling else problem.

Ví dụ,

if(blah) 
    if (more blah) 
     // do some blah 
else 
    // no blah I suppose 

Nếu không có dấu ngoặc nhọn, những thứ khác là mơ hồ bởi vì bạn không biết nếu nó liên quan đến việc đầu tiên hoặc thứ hai nếu tuyên bố. Vì vậy, bạn phải dự phòng trên một trình biên dịch (ví dụ trong Pascal hoặc C, trình biên dịch giả định sự lúng túng khác được liên kết với câu lệnh if gần nhất) để giải quyết sự mơ hồ hoặc không biên dịch hoàn toàn nếu bạn không muốn cho phép sự mơ hồ như vậy ngay từ đầu.

Tương tự,

try 
    try 
     // some code that throws! 
catch(some blah) 
    // which try block are we catching??? 
catch(more blah) 
    // not so sure... 
finally 
    // totally unclear what try this is associated with. 

Bạn có thể giải quyết nó với một quy ước, nơi khối catch được luôn gắn liền với những thử gần nhất, nhưng tôi tìm thấy giải pháp này thường cho phép các lập trình viên để viết mã đó là nguy hiểm tiềm tàng. Ví dụ: trong C, điều này:

if(blah) 
    if(more blah) 
     x = blah; 
    else 
     x = blahblah; 

... là cách trình biên dịch sẽ hiểu điều này nếu/nếu/khối khác. Tuy nhiên, nó cũng hoàn toàn hợp pháp để vít lên thụt của bạn và viết:

if(blah) 
    if(more blah) 
     x = blah; 
else 
    x = blahblah; 

... mà bây giờ làm cho nó xuất hiện như khác được kết hợp với bên ngoài câu lệnh if, trong khi thực tế nó được kết hợp với bên trong nếu tuyên bố do các công ước C. Vì vậy, tôi nghĩ rằng yêu cầu niềng răng đi một chặng đường dài hướng tới giải quyết sự mơ hồ và ngăn chặn một lỗi khá lén lút (những loại vấn đề có thể được tầm thường để bỏ lỡ, ngay cả trong kiểm tra mã). Các ngôn ngữ như python không có vấn đề này kể từ khi thụt đầu dòng và vấn đề khoảng trắng.

Answer 9

Nếu bạn cho rằng các nhà thiết kế của C# đơn giản chọn sử dụng cú pháp giống như C++ thì câu hỏi sẽ trở thành lý do tại sao dấu ngoặc đơn cần thiết với các câu lệnh đơn thử và bắt khối trong C++. Câu trả lời đơn giản là Bjarne Stroustrup cho rằng cú pháp dễ giải thích hơn.

Trong The Design and Evolution of C++ Stroustrup viết:

"Từ khóa thử là hoàn toàn không cần thiết và do đó là những {} niềng răng 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."

Anh ấy tiếp tục đưa ra ví dụ trong đó từ khóa thử và {} là không cần thiết. Sau đó, ông viết:

"Tuy nhiên, tôi thấy điều này rất khó giải thích rằng dự phòng đã được giới thiệu để tiết kiệm nhân viên hỗ trợ từ người dùng nhầm lẫn".

Tham chiếu: Stroustrup, Bjarne (1994). Thiết kế và sự tiến hóa của C++. Addison-Wesley.

Answer 10

Một cách khác để nhìn vào này ...

Với tất cả những vấn đề bảo trì đã được tạo ra bởi “nếu”, “trong khi”, “cho” và tuyên bố “foreach” không có căn cứ, rất nhiều công ty đã mã hóa các tiêu chuẩn luôn yêu cầu căn cứ vào các tuyên bố hoạt động trên một “khối”.

Vì vậy, họ làm cho bạn viết:

if (itIsSo) 
{ 
ASingleLineOfCode(); 
} 

Thay sau đó:

if (itIsSo) 
ASingleLineOfCode(); 

(Lưu ý là thụt không được chọn bởi trình biên dịch, nó không thể được phụ thuộc vào là đúng)

Một trường hợp tốt có thể được thực hiện để thiết kế một ngôn ngữ luôn đòi hỏi các căn cứ, nhưng sau đó quá nhiều người sẽ ghét C# do phải luôn luôn sử dụng các căn cứ. Tuy nhiên để thử/nắm bắt không có một kỳ vọng của việc có thể nhận được đi mà không sử dụng các căn cứ, do đó, nó đã có thể yêu cầu họ mà không có nhiều người phàn nàn.

---

Cho một lựa chọn, tôi sẽ có nhiều nếu/endIf (và while/endWhile) làm khối phân cách nhưng Hoa Kỳ đã đi theo cách đó. (C có để xác định những gì hầu hết ngôn ngữ giống như hơn module2, rốt cuộc cả hầu hết những gì chúng tôi được xác định bởi lịch sử không logic)