Tôi đang gặp khó khăn trong việc quyết định cách xử lý các ngoại lệ trong ứng dụng của mình.
Phần lớn nếu các vấn đề của tôi với các ngoại lệ xuất phát từ 1) truy cập dữ liệu thông qua một dịch vụ từ xa hoặc 2) giải mã hóa đối tượng JSON. Rất tiếc, tôi không thể đảm bảo thành công cho một trong hai tác vụ này (cắt kết nối mạng, đối tượng JSON không đúng định dạng nằm ngoài tầm kiểm soát của tôi).
Kết quả là, nếu tôi gặp một ngoại lệ, tôi chỉ cần bắt nó trong hàm và trả về FALSE cho người gọi. Logic của tôi là tất cả những gì người gọi thực sự quan tâm là nếu nhiệm vụ thành công, chứ không phải tại sao nó không thành công.
Đây là một số mã mẫu (trong JAVA) của một phương pháp điển hình)
public boolean doSomething(Object p_somthingToDoOn)
{
boolean result = false;
try{
// if dirty object then clean
doactualStuffOnObject(p_jsonObject);
//assume success (no exception thrown)
result = true;
}
catch(Exception Ex)
{
//don't care about exceptions
Ex.printStackTrace();
}
return result;
}Tôi nghĩ rằng cách tiếp cận này là tốt, nhưng tôi thực sự tò mò muốn biết các phương pháp hay nhất để quản lý các ngoại lệ là gì (liệu tôi có thực sự nên đánh dấu một ngoại lệ trong suốt quá trình ngăn xếp cuộc gọi không?).
Tóm tắt các câu hỏi chính:
- Có ổn không nếu chỉ bắt các ngoại lệ nhưng không làm bong bóng chúng hoặc thông báo chính thức cho hệ thống (thông qua nhật ký hoặc thông báo cho người dùng)?
- Có những phương pháp hay nhất nào dành cho các trường hợp ngoại lệ không dẫn đến mọi thứ yêu cầu khối thử / bắt?
Theo dõi / Chỉnh sửa
Cảm ơn tất cả các phản hồi, đã tìm thấy một số nguồn tuyệt vời về quản lý ngoại lệ trực tuyến:
- Các phương pháp hay nhất để xử lý ngoại lệ | O'Reilly Media
- Các phương pháp hay nhất về xử lý ngoại lệ trong .NET
- Các phương pháp hay nhất: Quản lý ngoại lệ (Bài viết hiện trỏ đến bản sao archive.org)
- Các phản vật chất xử lý ngoại lệ
Có vẻ như quản lý ngoại lệ là một trong những thứ thay đổi tùy theo ngữ cảnh. Nhưng quan trọng nhất, người ta phải nhất quán trong cách họ quản lý các ngoại lệ trong hệ thống.
Ngoài ra, hãy chú ý đến sự thối mã do thử / bắt quá nhiều hoặc không đưa ra một ngoại lệ nào đó (một ngoại lệ là cảnh báo hệ thống, những gì khác cần được cảnh báo?).
Ngoài ra, đây là một bình luận khá lựa chọn từ m3rLinEz .
Tôi có xu hướng đồng ý với Anders Hejlsberg và bạn rằng hầu hết những người gọi điện chỉ quan tâm xem hoạt động có thành công hay không.
Từ nhận xét này, nó đưa ra một số câu hỏi cần suy nghĩ khi xử lý các trường hợp ngoại lệ:
- Điểm ngoại lệ này được ném là gì?
- Làm thế nào nó có ý nghĩa để xử lý nó?
- Người gọi có thực sự quan tâm đến ngoại lệ hay họ chỉ quan tâm cuộc gọi có thành công hay không?
- Việc buộc người gọi quản lý một trường hợp ngoại lệ tiềm năng có được ưu đãi không?
- Bạn có đang tôn trọng các idoms của ngôn ngữ không?
- Bạn có thực sự cần trả về cờ thành công như boolean không? Trả về boolean (hoặc int) là một tư duy C hơn là một Java (trong Java, bạn sẽ chỉ xử lý ngoại lệ).
- Làm theo các cấu trúc quản lý lỗi được liên kết với ngôn ngữ :)!