Có sử dụng điều khoản bảo vệ hoặc bắt ngoại lệ tốt hơn không?

Question

là tốt hơn để ngăn chặn ngoại lệ với một điều khoản bảo vệ hoặc bắt ngoại lệ? Có phương pháp hay nhất? Ưu và nhược điểm của hai phương pháp?

Ví dụ là tốt hơn này:

try 
{ 
    param=myArray[3]; 
} 
catch (IndexOutOfRangeException e) 
{ 
    do something... 
} 

hay này:

if(myArray.Length < 4) 
{ 
    do something... 
} 
else 
{ 
    param=myArray[3]; 
} 

Cảm ơn tất cả các bạn cho câu trả lời :)

Answer 1

tốt hơn là ngăn ngoại lệ với điều khoản bảo vệ hoặc bắt ngoại lệ?

Trong trường hợp ngoại lệ "có tiêu đề" như chỉ mục nằm ngoài phạm vi, luôn là tên cũ.

Trong trường hợp ngoại lệ "ngoại sinh", luôn là ngoại lệ.

Ưu và nhược điểm của hai phương pháp?

Chỉ có nhược điểm của trường hợp sau trong trường hợp ngoại lệ có đầu mối. Chúng là:

• Ngoại lệ là cực kỳ đắt tiền so với thử nghiệm.
• Trường hợp ngoại lệ được thiết kế để mô hình đặc biệt hiếm hoi tình huống luồng điều khiển; nếu có khả năng truy cập vào một chỉ mục nằm ngoài phạm vi là bình thường thì không viết xử lý ngoại lệ.
• Trường hợp ngoại lệ được báo cáo là ngoại lệ "cơ hội đầu tiên" đối với người nghe ngay cả khi ngoại lệ được xử lý. Nhiều hệ thống - ví dụ: - lắng nghe các ngoại lệ cơ hội đầu tiên, ghi lại tất cả các trường hợp đó và xử lý các thành phần tạo ra nhiều trường hợp như lỗi, vì chúng là. (Tôi đã từng giới thiệu một ngoại lệ cơ hội đầu tiên có chủ ý trong một đường dẫn mã phổ biến trong ASP và một ngày sau đó cậu bé đã nghe về nó. Các thử nghiệm hệ thống con bị lỗi phát điên.)
• Có một số ngoại lệ mà tôi gọi là ngoại lệ "có tiêu đề" - không có tham số, chỉ mục ngoài phạm vi, v.v. - vì chúng rất dễ tránh và cho biết lỗi nên rõ ràng nguy hiểm đến mức chúng luôn luôn được coi là lỗi nghiêm trọng và không bao giờ được xử lý (trừ khi "trình xử lý" đang ghi nhật ký chúng trước khi tắt quá trình.) Không xử lý lỗi, xóa lỗi.

Cuối cùng, bạn nên đọc bài viết của tôi về chủ đề này.

http://ericlippert.com/2008/09/10/vexing-exceptions/

Answer 2

Sử dụng một điều khoản bảo vệ - bắt ngoại lệ phát sinh cao chi phí thời gian chạy và nói chung để cải thiện khả năng đọc, bạn chỉ nên sử dụng ngoại lệ cho các điều kiện lỗi, không áp dụng cho luồng điều khiển thông thường

Answer 3

Trong trường hợp ngoại lệ có thể được ngăn chặn, hãy ngăn chặn nó. Luôn luôn.

Đánh bắt và xử lý Ngoại lệ rất tốn kém và không bao giờ được sử dụng cho luồng điều khiển thông thường. Một lính canh rẻ và dễ dàng.

Answer 4

Điều khoản bảo vệ. Bạn không bao giờ muốn sử dụng try/catch cho luồng điều khiển. Bắt ngoại lệ là tốn kém và nên tránh càng nhiều càng tốt.