Phương thứcA gọi một Phương thứcB mà lần lượt gọi Phương thức.

KHÔNG có xử lý ngoại lệ trong Phương thứcB hoặc Phương thứcC. Nhưng có xử lý ngoại lệ trong Phương thứcA.

Trong Phương thứcC, một ngoại lệ xảy ra.

Bây giờ, ngoại lệ đó đang sủi bọt lên Phương thức, xử lý nó một cách thích hợp.

Điều gì là sai với điều này?

Trong tâm trí của tôi, tại một thời điểm nào đó, người gọi sẽ thực thi Phương thứcB hoặc Phương thức và khi các ngoại lệ xảy ra trong các phương thức đó, những gì sẽ thu được từ việc xử lý các ngoại lệ bên trong các phương thức đó, về cơ bản chỉ là một khối thử / bắt / cuối cùng thay vì chỉ cho phép họ bong bóng lên đến callee?

Tuyên bố hoặc sự đồng thuận xung quanh việc xử lý ngoại lệ là đưa ra khi việc thực thi không thể tiếp tục do điều đó - một ngoại lệ. Tôi hiểu rồi Nhưng tại sao không bắt ngoại lệ xa hơn trên chuỗi thay vì phải thử / bắt khối hoàn toàn.

Tôi hiểu nó khi bạn cần giải phóng tài nguyên. Đó là một vấn đề hoàn toàn khác.

Theo nguyên tắc chung, đừng bắt ngoại lệ trừ khi bạn biết phải làm gì với chúng. Nếu MethodC ném một ngoại lệ, nhưng Phương thứcB không có cách nào hữu ích để xử lý nó, thì nó sẽ cho phép ngoại lệ đó lan truyền lên Phương thứcA.

Những lý do duy nhất tại sao một phương thức nên có cơ chế bắt và rút lại là:

• Bạn muốn chuyển đổi một ngoại lệ thành một ngoại lệ khác có ý nghĩa hơn đối với người gọi ở trên.
• Bạn muốn thêm thông tin vào ngoại lệ.
• Bạn cần một mệnh đề bắt để dọn sạch các tài nguyên sẽ bị rò rỉ mà không có tài nguyên.

Mặt khác, việc bắt các ngoại lệ ở cấp độ sai có xu hướng dẫn đến mã bị âm thầm thất bại mà không cung cấp bất kỳ phản hồi hữu ích nào cho mã gọi (và cuối cùng là người dùng phần mềm). Việc thay thế bắt một ngoại lệ và sau đó ngay lập tức nghĩ lại là vô nghĩa.

Điều gì là sai với điều này?

Hoàn toàn không có gì.

Bây giờ, ngoại lệ đó đang sủi bọt lên Phương thức, xử lý nó một cách thích hợp.

"Xử lý nó một cách thích hợp" là phần quan trọng. Đó là mấu chốt của Xử lý ngoại lệ có cấu trúc.

Nếu mã của bạn có thể làm điều gì đó "hữu ích" với Ngoại lệ, hãy thực hiện. Nếu không thì hãy để yên.

. . . tại sao không bắt ngoại lệ xa hơn trên chuỗi thay vì phải thử / bắt khối hoàn toàn.

Đó chính xác là những gì bạn nên làm. Nếu bạn đang đọc mã có trình xử lý / bộ nhớ lại "hết cỡ", thì có lẽ bạn [có thể] đang đọc một số mã khá kém.

Đáng buồn thay, một số Nhà phát triển chỉ xem các khối bắt là mã "nồi hơi" mà họ ném vào (không có ý định chơi chữ) cho mọi phương thức họ viết, thường là vì họ không thực sự "lấy" Xử lý ngoại lệ và nghĩ rằng họ phải thêm một cái gì đó rằng Ngoại lệ không "thoát" và giết chương trình của họ.

Một phần của khó khăn ở đây là, hầu hết thời gian, vấn đề này thậm chí sẽ không được chú ý, bởi vì Ngoại lệ không bị ném mọi lúc, nhưng khi có , chương trình sẽ lãng phí rất nhiều thời gian và Nỗ lực dần dần bỏ chọn ngăn xếp cuộc gọi để đến một nơi thực sự có ích với Exception.

Bạn phải tạo sự khác biệt giữa Thư viện và Ứng dụng.

Thư viện có thể ném ngoại lệ không bị bắt

Khi bạn thiết kế một thư viện, đến một lúc nào đó bạn phải suy nghĩ về những gì có thể sai. Các tham số có thể nằm trong phạm vi sai hoặc null, tài nguyên bên ngoài có thể không khả dụng, v.v.

Thư viện của bạn thường không có cách nào để đối phó với chúng một cách hợp lý . Giải pháp hợp lý duy nhất là đưa ra một Ngoại lệ phù hợp và để nhà phát triển Ứng dụng giải quyết.

Các ứng dụng phải luôn luôn ở một số điểm ngoại lệ

Khi một ngoại lệ bị bắt, tôi muốn phân loại chúng là Lỗi hoặc Lỗi nghiêm trọng . Lỗi thông thường có nghĩa là một thao tác trong Ứng dụng của tôi không thành công. Chẳng hạn, một tài liệu mở không thể được lưu, vì đích không thể ghi được. Suy nghĩ hợp lý duy nhất để Ứng dụng thực hiện là thông báo cho người dùng rằng thao tác không thể hoàn thành thành công, cung cấp thông tin có thể đọc được cho con người liên quan đến vấn đề và sau đó để người dùng quyết định làm gì tiếp theo.

Một Lỗi Fatal là một lỗi logic ứng dụng chính không thể phục hồi từ. Chẳng hạn, nếu trình điều khiển thiết bị đồ họa gặp sự cố trong trò chơi video, không có cách nào để Ứng dụng "duyên dáng" thông báo cho người dùng. Trong trường hợp này, một tệp nhật ký nên được viết và, nếu có thể, người dùng nên được thông báo bằng cách này hay cách khác.

Ngay cả trong trường hợp nghiêm trọng như vậy, Ứng dụng nên xử lý Ngoại lệ này một cách có ý nghĩa. Điều này có thể bao gồm viết tệp Nhật ký, gửi Báo cáo sự cố, v.v. Không có lý do gì để Ứng dụng không phản hồi Ngoại lệ theo một cách nào đó.

Có gì sai với mẫu bạn mô tả là phương pháp A sẽ không có cách phân biệt giữa ba kịch bản:

1. Phương pháp B thất bại trong một dự đoán.

2. Phương pháp C thất bại theo cách không lường trước được bằng phương pháp B, nhưng trong khi phương pháp B đang thực hiện một thao tác có thể bị từ bỏ một cách an toàn.

3. Phương pháp C thất bại theo cách không được dự đoán trước bởi phương pháp B, nhưng trong khi phương pháp B đang thực hiện một thao tác đặt mọi thứ ở trạng thái được cho là tạm thời tạm thời mà B không thể dọn dẹp vì thất bại của C.

Cách duy nhất mà phương pháp A sẽ có thể phân biệt các kịch bản đó là nếu ngoại lệ được ném từ B bao gồm đủ thông tin cho mục đích đó hoặc nếu ngăn xếp mở ra cho phương thức B làm cho đối tượng bị bỏ lại ở trạng thái bị vô hiệu rõ ràng . Thật không may, hầu hết các khung ngoại lệ làm cho cả hai mẫu trở nên lúng túng, buộc các lập trình viên phải đưa ra quyết định thiết kế "ít tệ hơn".