Các lớp học được sử dụng để quản lý ngoại lệ

Question

Bạn có thể học một lớp học với các phương pháp ngắn để bắt ngoại lệ không?

class ContractUtils{ 
    public static String getCode(Contract contract) throws MyException{ 
    try{ 
     return contract.getInfo().getCode(); //throws ContractException and LogicException 
    }catch(Exception e){ 
     throw new MyException("error during code reading:"+e.getMessage, e); 
    } 
    } 
    //other methods like above... 
} 

Answer 1

lớp tiện ích của bạn ContractUtil giới thiệu một mức độ gián tiếp chỉ để dịch các ngoại lệ ban đầu vào ngoại lệ khác:

Thay vì các cuộc gọi trực tiếp:

return contract.getInfo().getCode() 

bây giờ bạn đang viết càng nhân tạo

return ContractUtils.getCode(contract); 

Nhưng có thể có những tình huống mà giải pháp này có thể được biện minh , ví dụ .:

Bạn đang không được phép ném ContractException hoặc LogicException, và bạn đang gọi phương pháp này rất nhiều lần.

Nhưng nếu bạn có thể thay đổi chữ ký, tốt hơn hết là thiết kế lại phương thức gốc để chỉ ném MyException.

Answer 2

Luôn luôn nắm bắt và xử lý ngoại lệ riêng biệt trong mã của bạn. Chỉ định một ngoại lệ tùy chỉnh chung không được khuyến nghị.

Tham khảo link này để thực hành tốt nhất trong việc quản lý hợp ngoại lệ:

https://softwareengineering.stackexchange.com/questions/209693/best-practices-to-create-error-codes-pattern-for-an-enterprise-project-in-c

Answer 3

Nếu một ngoại lệ tùy chỉnh cung cấp thêm ngữ cảnh hoặc giá trị cho mã gọi, thì đó là hữu ích và khuyến khích để tạo ra chúng.

Bạn đang sử dụng phương pháp tĩnh hoàn toàn có thể chấp nhận được. Dưới đây là một trường hợp sử dụng tốt SO answer xác định các phương pháp tĩnh ngắn.

Answer 4

Có thể hữu ích khi tách logic ứng dụng khỏi xử lý lỗi để dễ đọc.

Nhưng không phải trong lớp tiện ích vì bạn có thể quên sử dụng nó, và hoàn thành nhiệm vụ của mình trực tiếp và vẫn mong đợi một ngoại lệ tùy chỉnh. Tôi sẽ đặt logic này trong lớp Contact nếu nó được sử dụng thường xuyên (và làm cho Contract.getInfo() riêng). Một nhược điểm nữa là, nó có thể dẫn đến các lớp tiện ích quá thông thái (LoD - https://en.wikipedia.org/wiki/Law_of_Demeter) về các chi tiết thực hiện của các lớp khác, có thể phá vỡ đóng gói và làm cho chúng ít được bảo trì hơn do phụ thuộc cao hơn.

Và bạn có thể muốn có ngoại lệ cụ thể.