Có lý do nào để KHÔNG sử dụng các lớp ngoại lệ do .NET Framework định nghĩa trong mã của riêng bạn không?

Question

Vì vậy, chúng tôi đang sử dụng Enterprise Library 4.1 Exception Handling Application Block để xử lý việc ghi nhật ký/xử lý các ngoại lệ của chúng tôi trong một ứng dụng nhiều dự án. Chúng tôi có một vài ngoại lệ tùy chỉnh và đang ném một số ngoại lệ có các lớp được định nghĩa trong thư viện lớp chuẩn của khung công tác .NET (ví dụ: ArgumentException, InvalidOperationException, ArgumentNullException, v.v.). Hôm nay, nhóm trưởng của chúng tôi quyết định rằng anh ấy không muốn chúng tôi sử dụng thứ hai, vì khuôn khổ .NET sẽ ném các loại ngoại lệ đó, và để tạo điều kiện lọc với các chính sách của khối ứng dụng, chúng tôi chỉ nên sử dụng trường hợp ngoại lệ tùy chỉnh, đi xa như vậy để thực tế lặp lại .NET tiêu chuẩn ngoại lệ thư viện lớp với các phiên bản tùy chỉnh, như trong tuỳ chỉnh ArgumentException, tuỳ chỉnh InvalidOperationException vv

câu hỏi của tôi là, những gì là sai với phương pháp này? Tôi không thể đặt ngón tay vào lúc đó, nhưng nó có mùi sai với tôi và tôi đã không thể lay chuyển những cảm giác khó chịu của tôi về nó. Tôi có lo lắng về điều gì đó thực sự không phải là một vấn đề lớn? Tôi đoán nó chỉ cảm thấy như đuôi vẫy con chó một chút ở đây ...

Answer 1

Ick. Những gì tôi không thích về nó là:

• Nó bản sao các loại hiện có
• Nó vi phạm nguyên tắc tối thiểu ngạc nhiên
• Điều đó có nghĩa rằng nếu bạn muốn tìm ở khắp mọi nơi bạn đã sử dụng giá trị đối số sai (nói) bạn phải tìm hai loại hệ thống cấp bậc ngoại lệ thay vì chỉ tìm kiếm ArgumentException.

Tôi khuyên bạn nên dẫn dắt nhóm của bạn đọc mục 60 của Effective Java 2nd edition. Vâng, đó là về Java thay vì C# - nhưng nguyên tắc vẫn như cũ.

Answer 2

Vâng, trường hợp ngoại lệ được ném bởi mã của bạn và ném bởi các lớp .net cơ sở cả hai đều phải được xử lý theo cùng một cách.

Cả hai có thể là triệu chứng của sự cố trong mã mã của bạn, vì vậy không nên bỏ qua hoặc lọc!

Answer 3

Sách Framework Design Guidelines (ấn bản đầu tiên) của Krzysztof Cwalina và Brad Abrams khuyên bạn nên ném các ngoại lệ hiện có được xác định trong các không gian tên System nơi bạn có thể, và càng cụ thể càng tốt. Nếu không có sự phù hợp tốt thì hãy ném một ngoại lệ tùy chỉnh.

Tạo một vũ trụ song song của Tuỳ chỉnhArgumentNullException để phù hợp với System.ArgumentNullException là một sự trùng lặp của nỗ lực mà tôi không thấy bất kỳ giá trị trong. Vào cuối ngày nếu mã của bạn ném một System.ArgumentNullException chứ không phải là một lớp khung bạn có thể xác định từ dấu vết ngăn xếp người chịu trách nhiệm cuối cùng.

Mùi của công việc phụ không cần thiết này cho hiện tại và trong tương lai khi nói đến thời gian bảo trì mã.

Answer 4

Ném ngoại lệ .Net là tốt khi ngoại lệ mô tả đúng loại vấn đề bạn đang cố gắng vạch trần (ví dụ: khi đối số là null, bạn nên ném một ArgumentNullException). Nếu bạn thấy một tình huống không được xử lý bởi khung .Net (ví dụ: Bạn muốn chia 6 cho 3 nhưng điều đó không được ứng dụng của bạn cho phép), bạn nên tạo một ngoại lệ tùy chỉnh.

Answer 5

Tôi lặp lại câu trả lời của Jon Skeet và Kev. Tôi chỉ muốn thêm rằng nếu chính sách ngoại lệ của bạn muốn xử lý các ngoại lệ cấp khuôn khổ khác với ngoại lệ của riêng bạn, hãy xem xét sử dụng dấu vết ngăn xếp của ngoại lệ.

// Somewhere within a custom exception handler policy 
var frame = new StackTrace(exception).GetFrame(0); 
if (frame.GetMethod().DeclaringType.Namespace.StartsWith("MyNamespace.")) 
{ 
    // Handle exceptions from our code 
} 
else 
{ 
    // Handle framework-level exceptions 
}