2010-04-30 13 views
11

Tôi đã có ví dụ một try/catch trong phương pháp của tôi:Thoát try/catch để ngăn chặn mã sau từ được chạy

} 
    catch (OurCustomExceptionObject1 ex) 
    { 
     txtErrorMessage.InnerHtml = "test 1"; 
    } 
    catch(OurCustomExceptionObject2 ex) 
    { 
     txtErrorMessage.InnerHtml = "test 2"; 
    } 
    catch (OurCustomExceptionObject3 ex) 
    { 
     txtErrorMessage.InnerHtml = "test 3"; 
    } 

    ... rest of code here is being executed after the try/catch 

Tôi không muốn phần còn lại của mã để chạy nếu một trong các trường hợp ngoại lệ bị bắt. Tôi đang xử lý các ngoại lệ. Tôi nghe nói không sử dụng Exit Hãy thử một số lý do. Điều đó có đúng không, thật tệ khi làm điều này? Đây có phải là cách đúng để tạm dừng thực thi mã sau đó phát biểu khai thác không?

+1

'Thoát Thử' chỉ tồn tại trong VB.NET. Nó không áp dụng cho C#. Trong C#, tính năng ngôn ngữ tương ứng sẽ là 'break', nhưng đó là bất hợp pháp trong một khối' try..catch..finally'. Điều tốt nhất tiếp theo sẽ là 'return', mà không làm như vậy, nhưng là một điều hoàn toàn hợp pháp để làm. – stakx

+0

@stakx 'break' không phải là bất hợp pháp trong khối' catch'. Nó có thể được sử dụng để thoát khỏi vòng lặp. –

Trả lời

30

Hoặc là return trong khối catch, rút ​​lại ngoại lệ hoặc di chuyển mã từ bên dưới khối thử bên trong khối thử.

+0

Chính xác những gì tôi định trả lời – BlitzKrieg

+2

Đúng. Và tôi nghĩ việc chuyển mã là cách tiếp cận tốt nhất trong trường hợp này. Nếu bạn muốn dừng mã tiếp tục khi có ngoại lệ - không làm gì cả. Một ngoại lệ đã làm gián đoạn luồng thực thi. Chỉ cần bao quanh toàn bộ điều với một thử-catch nếu bạn muốn xử lý các hoạt động quá. Mặc dù nếu đó là một phương pháp, tôi sẽ bao quanh các cuộc gọi phương thức chứ không phải là cơ thể phương pháp, do đó, ngoại lệ không được nuốt vô tình. –

+0

đúng vậy. nhưng trong trường hợp của tôi phần còn lại của mã rất nhiều. là ok để đặt một số lượng lớn mã trong một tuyên bố thử? bởi vì thế thì mọi sự bắt giữ trong phần đó sẽ bị bắt dưới cái bẫy cuối cùng và ví dụ tôi sẽ không thể nào ngoại lệ đề cập đến đâu. – Disasterkid

1

Hai lựa chọn ngay lập tức tôi suy nghĩ:

  1. return trực tiếp từ bên trong mỗi catch (như BlueRaja gợi ý)
  2. thiết lập một lá cờ (ví dụ, errorOccurred) trong catch khối cho trường hợp ngoại lệ bạn không muốn cho phép, sau đó đặt if (errorOccurred) return; sau khi khối toàn try/catch

sau sức được rea hơn dable cho các nhà phát triển khác, vì nó dễ dàng để lướt qua những gì xảy ra bên trong một catch để tìm ra những gì xảy ra sau đó. Nhìn thấy một chữ số if (errorOccurred) return; trắng trợn làm cho việc hiểu nhầm điều gì đã xảy ra.

1

Từ chế độ xem ở mức cao, tôi cho rằng điều này có thể vi phạm (ít nhất) Nguyên tắc về trách nhiệm duy nhất nếu mã của bạn đang cố thực hiện điều gì đó có thể không thành công và sau đó tiếp tục thực hiện một số nội dung khác.

Vì lợi ích của một câu trả lời tuy nhiên, nếu bạn muốn làm một hack (mà luôn luôn là xấu, do đó, không), bạn có thể làm

bool success = true; 
try 
{ 
    // the good ol' college try 
} 
catch (...) 
{ 
    success = false; 
} 

if (success) 
{ 
    // do the rest of your stuff 
} 

chỉnh sửa: hoặc cách khác như BlueRaja đề nghị, đặt tất cả mã của bạn vào khối thử. Nếu bit đầu tiên không thành công, nó sẽ thất bại. Phần còn lại của mã sẽ không chạy anyway.

+0

Tôi không biết về điều đó. Tất cả phụ thuộc vào tình hình và logic cần phải diễn ra. Tôi không thấy lý do tại sao việc xử lý sau sẽ làm tổn thương bất cứ điều gì nếu tất cả những gì bạn đang làm để xử lý các lỗi dự kiến ​​là bằng cách đăng nhập và chuyển sang mã tiếp theo trong phương thức sau khi bắt. – PositiveGuy

Các vấn đề liên quan