Thực tiễn tốt này cho Ngoại lệ tùy chỉnh?

Question

public class PageNotFoundException : HttpException 
{ 
    public PageNotFoundException() 
     : base(404, "HTTP/1.1 404 Not Found") 
    { 

    } 
} 

Ý tưởng là thay vì gõ này mỗi lần

throw new HttpException(404, "HTTP/1.1 404 Not Found") 

Tôi thà viết

throw new PageNotFoundException(); 

tôi sẽ thêm một tình trạng quá tải cho bao gồm cả InnerException tuy nhiên tôi sẽ không bao giờ sử dụng điều này trong một khối try/catch.

Bạn có cân nhắc thực tiễn tốt này không?
tức là Thừa kế từ một ngoại lệ và chuyển thông tin được mã hóa cứng tới cơ sở (...).

Answer 1

Tôi quyết định viết lại câu trả lời của mình để cụ thể cho câu hỏi thực tế của bạn và theo nghĩa rộng hơn, ứng dụng MVC không phải là điều duy nhất áp dụng tốt nhất.

(1) Trả lời. Đây không phải là thực hành tốt. Bạn nên sử dụng một phương thức trình tạo ngoại lệ thay vì ném trực tiếp HttpException.

public static void ThrowPageNotFoundException() { 
    throw new HttpException((Int32)HttpStatusCode.NotFound, "HTTP/1.1 404 Not Found"); 
} 

(2) DO. Sử dụng các phương thức trình tạo ngoại lệ (ví dụ: mã tôi đã cung cấp). Điều này cho phép bạn tránh chi phí hiệu suất bổ sung của việc có loại ngoại lệ của riêng bạn và cho phép nó được inlined. Các thành viên ném ngoại lệ không được inlined. Đây sẽ là sự thay thế thích hợp cho việc ném thuận tiện.

(3) DO.Sử dụng ngoại lệ của thư viện lớp cơ sở bất cứ khi nào có thể và chỉ tạo ngoại lệ tùy chỉnh khi hoàn toàn không có ngoại lệ cơ sở đáp ứng các yêu cầu cần thiết. Tạo các ngoại lệ tùy chỉnh bổ sung thêm hệ thống phân cấp ngoại lệ sâu hơn, điều này làm cho việc gỡ rối khó khăn hơn khi nó không cần, bổ sung thêm chi phí hiệu năng, và cũng bổ sung thêm bloat cho cơ sở mã của bạn.

(4) KHÔNG. Ném lớp cơ sở System.Exception. Thay vào đó, hãy sử dụng loại ngoại lệ cụ thể.

(5) KHÔNG. Tạo ngoại lệ tùy chỉnh để thuận tiện. Đây không phải là một lý do chính đáng cho một ngoại lệ tùy chỉnh, bởi vì các ngoại lệ về bản chất là tốn kém.

(6) KHÔNG. Tạo ngoại lệ tùy chỉnh chỉ để có loại ngoại lệ của riêng bạn.

(7) KHÔNG. Ném ngoại lệ có thể tránh được bằng cách thay đổi mã gọi. Điều này sẽ gợi ý rằng bạn có một lỗi khả năng sử dụng trong API thay vì một vấn đề thực tế.

Bất kỳ ai đã đọc Nguyên tắc thiết kế khung từ chuỗi phát triển .NET sẽ biết những thực tiễn này và thực hành rất tốt. Đây là những thực tế mà khung công tác .NET được xây dựng và MVC.

Answer 2

Nếu bạn là người ném ngoại lệ ngay từ đầu, thì có - OK. Tuy nhiên, nếu bạn bắt một số HttpException và sau đó thử ném một PageNotFoundException thay vào đó, bạn nên đặt ngoại lệ ban đầu là InnerException.

Answer 3

Trong khi đây là một cấu trúc tốt đẹp trong mã của riêng bạn để sử dụng riêng của bạn, một xem xét là nó có thể thúc đẩy mã hóa theo quy ước có thể nguy hiểm khi bạn đang giao dịch với các nhà phát triển mới/khác.

Trong thư viện của riêng bạn, nếu bạn nhất quán về việc ném một PageNotFoundException bất cứ khi nào một 404 HttpException nên được ném, nó có thể có ý nghĩa hơn đối với catch (PageNotFoundException). Tuy nhiên, khi bạn bắt đầu sử dụng các thư viện khác không có ngoại lệ tùy chỉnh của mình, bạn sẽ bỏ lỡ 404 HttpExceptions được ném bởi mã khác. Tương tự như vậy, nếu bạn có các nhà phát triển khác đóng góp vào một ngày sau đó (hoặc thậm chí bổ sung của bạn trong tương lai), việc xem xét rằng PageNotFoundExceptions là những gì bị bắt bởi hầu hết các chức năng có thể bị bỏ qua và 404 HttpExceptions mới có thể được ném vào các mô-đun mới , mà tương tự như vậy sẽ không bị bắt bởi mã gọi/sao chép/dán. Về cơ bản, các cấu trúc như thế này làm tăng thời gian thích nghi cần thiết để làm việc trên dự án, và phải được xử lý theo cách giảm thiểu chi phí này (dễ nhìn thấy trong thư viện đối tượng chia sẻ trung tâm dễ tìm thấy). đã quá lộn xộn).

Mặt khác, chắc chắn có giá trị trong việc tập trung hóa việc tạo ra các HttpExceptions của bạn nếu bạn đang tìm kiếm về cơ bản là các lợi ích mẫu của nhà máy; nó có thể là giá trị chỉ đi với điều đó thay vì nếu đó là những gì bạn đang cố gắng để có được ra khỏi nó (throw ExceptionFactory.NewPageNotFound()).