Tại sao chúng ta không ném những ngoại lệ này?

Tôi đã xem trang MSDN này nói rằng:

Không cố tình ném Exception , SystemException , NullReferenceException hoặc IndexOutOfRangeException khỏi mã nguồn của riêng bạn.

Thật không may, nó không bận tâm để giải thích tại sao. Tôi có thể đoán lý do nhưng tôi hy vọng rằng ai đó có thẩm quyền hơn về chủ đề này có thể cung cấp cái nhìn sâu sắc của họ.

Hai cái đầu tiên có ý nghĩa rõ ràng, nhưng hai cái sau có vẻ giống như những cái bạn muốn tuyển dụng (và trên thực tế, tôi có).

Hơn nữa, đây có phải là những ngoại lệ duy nhất mà người ta nên tránh không? Nếu có những người khác, họ là gì và tại sao họ cũng nên tránh?

Exceptionlà kiểu cơ sở cho tất cả các trường hợp ngoại lệ và như vậy là không cụ thể. Bạn không bao giờ nên ném ngoại lệ này vì nó chỉ đơn giản là không chứa bất kỳ thông tin hữu ích nào. Việc gọi mã bắt mã cho các ngoại lệ không thể phân biệt ngoại lệ được cố ý ném (theo logic của bạn) với các ngoại lệ hệ thống khác hoàn toàn không mong muốn và chỉ ra các lỗi thực sự.

Lý do tương tự cũng áp dụng cho SystemException. Nếu bạn nhìn vào danh sách các kiểu dẫn xuất, bạn có thể thấy một số lượng lớn các ngoại lệ khác với ngữ nghĩa rất khác nhau.

NullReferenceExceptionvà IndexOutOfRangeExceptionthuộc một loại khác. Bây giờ đây là những ngoại lệ rất cụ thể, vì vậy bạn có thể ném chúng đi . Tuy nhiên, bạn vẫn sẽ không muốn ném chúng đi, vì chúng thường có nghĩa là có một số sai lầm thực tế trong logic của bạn. Ví dụ, ngoại lệ tham chiếu null có nghĩa là bạn đang cố gắng truy cập vào một thành viên của một đối tượng null. Nếu đó là một khả năng xảy ra trong mã của bạn, thì bạn nên luôn kiểm tra rõ ràng nullvà thay vào đó đưa ra một ngoại lệ hữu ích hơn (ví dụ ArgumentNullException). Tương tự, IndexOutOfRangeExceptions xảy ra khi bạn truy cập một chỉ mục không hợp lệ (trên mảng — không phải danh sách). Bạn phải luôn đảm bảo rằng bạn không làm điều đó ngay từ đầu và kiểm tra ranh giới của ví dụ một mảng trước.

Ví dụ , có một vài trường hợp ngoại lệ khác như hai trường hợp đó InvalidCastExceptionhoặc DivideByZeroExceptionđược đưa ra cho các lỗi cụ thể trong mã của bạn và thường có nghĩa là bạn đang làm sai hoặc bạn không kiểm tra một số giá trị không hợp lệ trước. Bằng cách cố ý ném chúng khỏi mã của bạn, bạn chỉ làm cho mã gọi khó xác định xem chúng bị ném do lỗi nào đó trong mã hay chỉ vì bạn quyết định sử dụng lại chúng cho một cái gì đó trong quá trình triển khai của mình.

Tất nhiên, có một số ngoại lệ (hah) đối với các quy tắc này. Nếu bạn đang xây dựng một thứ gì đó có thể gây ra một ngoại lệ khớp chính xác với một cái hiện có, thì hãy thoải mái sử dụng cái đó, đặc biệt nếu bạn đang cố gắng khớp một số hành vi được tạo sẵn. Chỉ cần đảm bảo rằng bạn chọn một loại ngoại lệ rất cụ thể sau đó.

Nói chung, mặc dù vậy, trừ khi bạn tìm thấy một ngoại lệ (cụ thể) đáp ứng nhu cầu của mình, bạn nên luôn cân nhắc tạo các loại ngoại lệ của riêng mình cho các ngoại lệ dự kiến ​​cụ thể. Đặc biệt khi bạn đang viết mã thư viện, điều này có thể rất hữu ích để tách các nguồn ngoại lệ.

Tôi nghi ngờ mục đích với 2 cuối cùng là để tránh nhầm lẫn với các ngoại lệ có sẵn có ý nghĩa mong đợi. Tuy nhiên, tôi cho rằng nếu bạn đang duy trì ý định chính xác của ngoại lệ : thì đó là ý định chính xác throw. Ví dụ: nếu bạn đang viết một bộ sưu tập tùy chỉnh, nó có vẻ hoàn toàn hợp lý khi sử dụng IndexOutOfRangeException- rõ ràng và cụ thể hơn, IMO, hơn ArgumentOutOfRangeException. Và trong khi List<T>có thể chọn cái sau, có ít nhất 41 địa điểm (lịch sự của phản xạ) trong BCL (không bao gồm các mảng) ném theo yêu cầu IndexOutOfRangeException- không có địa điểm nào đủ "cấp thấp" để xứng đáng được miễn trừ đặc biệt. Vì vậy, tôi nghĩ bạn có thể lập luận rằng hướng dẫn đó là ngớ ngẩn. Tương tự,NullReferenceException khá hữu ích trong các phương thức mở rộng - nếu bạn muốn duy trì ngữ nghĩa rằng:

obj.SomeMethod(); // this is actually an extension method

ném một NullReferenceExceptionkhi objlà null.

Như bạn đã chỉ ra, trong bài viết Tạo và ném ngoại lệ (Hướng dẫn lập trình C #) với chủ đề Những điều cần tránh khi ném ngoại lệ , Microsoft thực sự liệt kê System.IndexOutOfRangeExceptionlà một loại ngoại lệ không nên cố ý ném khỏi mã nguồn của chính bạn.

Tuy nhiên, ngược lại, trong bài ném (C # Reference) , Microsoft dường như đã vi phạm các nguyên tắc của chính mình. Đây là một phương pháp mà Microsoft đã đưa vào ví dụ của nó:

static int GetNumber(int index)
{
    int[] nums = { 300, 600, 900 };
    if (index > nums.Length)
    {
        throw new IndexOutOfRangeException();
    }
    return nums[index];
}

Vì vậy, bản thân Microsoft không nhất quán vì nó thể hiện việc ném IndexOutOfRangeExceptionvào tài liệu của mình throw!

Điều này khiến tôi tin rằng ít nhất là đối với trường hợp của IndexOutOfRangeException, có thể có những trường hợp mà kiểu ngoại lệ đó có thể được lập trình viên ném ra và được coi là một phương pháp chấp nhận được.

Khi tôi đọc câu hỏi của bạn, tôi đã tự hỏi mình trong những điều kiện nào mà người ta muốn ném các loại ngoại lệ NullReferenceException, InvalidCastExceptionhoặc ArgumentOutOfRangeException.

Theo ý kiến ​​của tôi, khi gặp một trong những loại ngoại lệ đó, tôi (nhà phát triển) cảm thấy lo lắng bởi cảnh báo theo nghĩa rằng trình biên dịch đang nói chuyện với tôi. Vì vậy, việc cho phép bạn (nhà phát triển) ném các loại ngoại lệ như vậy tương đương với việc (trình biên dịch) bán trách nhiệm. Ví dụ, điều này cho thấy trình biên dịch bây giờ nên cho phép nhà phát triển quyết định xem có phải là một đối tượng hay không null. Nhưng việc xác định như vậy thực sự nên là công việc của trình biên dịch.

Tái bút: Kể từ năm 2003, tôi đã phát triển các ngoại lệ của riêng mình để tôi có thể ném chúng theo ý muốn. Tôi nghĩ rằng nó được coi là một thực tiễn tốt nhất để làm như vậy.

Đặt cuộc thảo luận về NullReferenceExceptionvà IndexOutOfBoundsExceptionsang một bên:

Còn về việc bắt và ném System.Exception. Tôi đã ném loại ngoại lệ này vào mã của mình rất nhiều và tôi chưa bao giờ bị nó làm cho mê mẩn. Tương tự, tôi rất thường xuyên bắt gặp Exceptionloại không cụ thể và nó cũng hoạt động khá tốt đối với tôi. Vậy, tại sao lại như vậy?

Thông thường người dùng tranh luận rằng họ có thể phân biệt nguyên nhân lỗi. Theo kinh nghiệm của tôi, chỉ có một số tình huống mà bạn muốn xử lý các loại ngoại lệ khác nhau theo cách khác nhau. Đối với những trường hợp đó, khi bạn mong đợi người dùng xử lý lỗi theo chương trình, bạn nên đưa ra một loại ngoại lệ cụ thể hơn. Đối với các trường hợp khác, tôi không bị thuyết phục bởi hướng dẫn thực hành tốt nhất chung.

Vì vậy, Exceptiontôi không thấy lý do gì để cấm điều này trong mọi trường hợp.

CHỈNH SỬA: cũng từ trang MSDN:

Không nên sử dụng ngoại lệ để thay đổi luồng chương trình như một phần của quá trình thực thi thông thường. Các ngoại lệ chỉ nên được sử dụng để báo cáo và xử lý các điều kiện lỗi.

Lạm dụng các mệnh đề bắt với logic riêng lẻ cho các loại ngoại lệ khác nhau cũng không phải là phương pháp hay nhất.