2012-03-08 33 views
7

Tôi nhớ đọc một số hướng dẫn xử lý ngoại lệ để kiểm tra các tham số null đã được khuyến khích. Lý do cho điều này là, nếu bạn để lại mã như là, một ngoại lệ sẽ được nâng lên (NullReferenceExcpetion) khi bạn cố gắng sử dụng tham số. Cách khác là kiểm tra một cách rõ ràng cho null và ném một ArgumentNullException.Xử lý hay không để xử lý các tham số null với ngoại lệ

Điều này mang lại hiệu quả tương tự nhưng bạn phải thêm các dòng mã. Bạn sẽ không bao giờ viết mã để xử lý ngoại lệ và do đó bạn thực sự sẽ gặp phải những lỗi này khi chạy thử và sau đó sửa mã để ngăn chặn các ngoại lệ xảy ra ngay từ đầu.

Tôi không nói rằng tôi đồng ý với hướng dẫn nhưng điều đó có ý nghĩa khi tôi đọc nó lần đầu tiên và vẫn có ý nghĩa.

Tôi thường kiểm tra các tham số null trên các phương thức không phải riêng tư nhưng để lại phương thức riêng để ném NullReferenceException.

Có ai biết nếu có bất kỳ thực hành hướng dẫn tốt nhất/thực tế nào về điều này để tôi có thể cập nhật phương pháp tiếp cận của mình nếu cần không?

+0

Không dứt khoát, nhưng sự khác biệt đối với tôi là một lập luận [Null] Ngoại lệ chỉ ra rằng đầu vào đã được xác nhận và cố tình từ chối, trong khi một NullReferenceException nghĩa là sử dụng không được kiểm soát của một tài liệu tham khảo unassigned (có thể thậm chí không vào thời điểm đó của cuộc gọi ban đầu), có thể là lỗi. Tôi có xu hướng sử dụng ArgumentNullException trên các phương thức công khai và Debug.Assert trong các phương thức riêng.Việc giải mã các dòng mã bổ sung có thể được giảm bớt một chút bằng cách sử dụng các đoạn mã để chèn các kiểm tra và ném rỗng. – shambulator

Trả lời

12

này mang lại cho tác dụng tương tự nhưng bạn dòng thêm đúng mã

Không nó không. Xem xét:

public void TransferMoney(Account from, Account to, decimal amount) 
{ 
    from.Debit(amount); 
    to.Credit(amount); 
} 

vs

public void TransferMoney(Account from, Account to, decimal amount) 
{ 
    // Ideally do them separately 
    if (from == null || to == null) 
    { 
     throw new ArgumentNullException(); 
    } 

    from.Debit(amount); 
    to.Credit(amount); 
} 

Cả hai sẽ thất bại với trường hợp ngoại lệ - nhưng một trong những đầu tiên sẽ thất bại đã gây ra một tác dụng phụ đầu tiên. Đó là xấu, và nên tránh nếu có thể.

(Rõ ràng trong một thực kịch bản này có lẽ sẽ là giao dịch, và sẽ không có hại thực tế thực hiện, nhưng bạn có quan điểm của tôi.)

Ngoài ra, nếu một tham số được sử dụng như một tham số cho một phương pháp - hoặc tệ hơn, được lưu trữ để sử dụng sau - bạn có thể kết thúc với ngoại lệ được ném từ một địa điểm khác nhau hoàn toàn, theo cách có thể làm cho nó hoàn toàn không rõ ràng vấn đề ban đầu là gì.

Tôi thường kiểm tra các tham số rỗng trên các phương thức không phải riêng tư nhưng để lại phương thức riêng để ném NullReferenceException.

Điều đó có vẻ như một chính sách khá hợp lý. Nếu một phương pháp riêng/nội bộ được gọi từ một số mã lông và tôi lo ngại rằng tôi có thể có những điều sai lầm, đôi khi tôi xác nhận nó ngay cả sau đó.

+0

@oleksii: Có, sẽ chỉnh sửa. –

0

Với séc, bạn có thể chuyển tên thông số trong trường hợp ngoại lệ, điều này giúp đơn giản hóa việc gỡ lỗi.

if (x == null) throw new ArgumentNullException(nameof(x));