Trong C #, có bất kỳ lý do chính đáng nào (ngoài một thông báo lỗi tốt hơn) để thêm kiểm tra null tham số vào mọi hàm trong đó null không phải là giá trị hợp lệ không? Rõ ràng, mã sử dụng s sẽ ném ra một ngoại lệ. Và việc kiểm tra như vậy làm cho mã chậm hơn và khó bảo trì hơn.
void f(SomeType s)
{
if (s == null)
{
throw new ArgumentNullException("s cannot be null.");
}
// Use s
}
Câu trả lời:
Có, có những lý do chính đáng:
NullReferenceExceptionBây giờ đối với sự phản đối của bạn:
Và khẳng định của bạn:
Rõ ràng, mã sử dụng s sẽ ném ra một ngoại lệ.
Có thật không? Xem xét:
void f(SomeType s)
{
// Use s
Console.WriteLine("I've got a message of {0}", s);
}
Điều đó sử dụng s, nhưng nó không ném ra một ngoại lệ. Nếu nó không hợp lệ slà null và điều đó cho thấy rằng có gì đó không ổn, thì một ngoại lệ là hành vi thích hợp nhất ở đây.
Bây giờ bạn đặt các kiểm tra xác thực đối số đó ở đâu là một vấn đề khác. Bạn có thể quyết định tin tưởng tất cả mã trong lớp của riêng mình, vì vậy đừng bận tâm đến các phương thức riêng tư. Bạn có thể quyết định tin tưởng phần còn lại của assembly của mình, vì vậy đừng bận tâm đến các phương pháp nội bộ. Bạn gần như chắc chắn nên xác nhận các đối số cho các phương thức công khai.
Một lưu ý phụ: quá tải hàm tạo một tham số của ArgumentNullExceptionchỉ nên là tên tham số, vì vậy thử nghiệm của bạn phải là:
if (s == null)
{
throw new ArgumentNullException("s");
}
Ngoài ra, bạn có thể tạo một phương thức mở rộng, cho phép phần nào ngắn gọn hơn:
s.ThrowIfNull("s");
Trong phiên bản của tôi về phương thức mở rộng (chung), tôi đặt nó trả về giá trị ban đầu nếu nó không phải null, cho phép bạn viết những thứ như:
this.name = name.ThrowIfNull("name");
Bạn cũng có thể có quá tải không lấy tên tham số, nếu bạn không quá bận tâm về điều đó.
ThrowIfEmptytrênICollection
Debug.Assert. Việc bắt lỗi trong quá trình sản xuất (trước khi chúng làm hỏng dữ liệu thực) thậm chí còn quan trọng hơn trong quá trình phát triển.
throw new ArgumentNullException(nameof(s))
Tôi đồng ý với Jon, nhưng tôi sẽ thêm một điều vào điều đó.
Thái độ của tôi về thời điểm thêm kiểm tra rỗng rõ ràng dựa trên các cơ sở sau:
throwcâu lệnh là câu lệnh .iflà một câu lệnh .throwtrongif (x == null) throw whatever;Nếu không có cách nào khả thi để thực thi câu lệnh đó thì nó không thể được kiểm tra và nên được thay thế bằng Debug.Assert(x != null);.
Nếu có một cách khả thi để câu lệnh đó được thực thi thì hãy viết câu lệnh đó, rồi viết một bài kiểm tra đơn vị thực hiện nó.
Điều đặc biệt quan trọng là các phương thức public của các loại public kiểm tra các đối số của chúng theo cách này; bạn không biết người dùng của bạn sẽ làm điều điên rồ gì. Hãy cho họ câu "Này bạn, bạn đang làm sai!" ngoại lệ càng sớm càng tốt.
Ngược lại, các phương thức private của các loại private có nhiều khả năng xảy ra trong trường hợp bạn kiểm soát các đối số và có thể đảm bảo chắc chắn rằng đối số không bao giờ là rỗng; sử dụng một khẳng định để ghi lại sự bất biến đó.
Nếu không có ifkiểm tra rõ ràng , có thể rất khó để tìm ra đó là gìnull nếu bạn không sở hữu mã.
Nếu bạn nhận được NullReferenceExceptiontừ sâu bên trong một thư viện mà không có mã nguồn, bạn có thể gặp rất nhiều khó khăn để tìm ra những gì bạn đã làm sai.
Những ifkiểm tra này sẽ không làm cho mã của bạn chậm hơn đáng kể.
Lưu ý rằng tham số của hàm ArgumentNullExceptiontạo là tên tham số, không phải là thông báo.
Mã của bạn phải là
if (s == null) throw new ArgumentNullException("s");
Tôi đã viết một đoạn mã để làm cho việc này dễ dàng hơn:
<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<CodeSnippet Format="1.0.0">
<Header>
<Title>Check for null arguments</Title>
<Shortcut>tna</Shortcut>
<Description>Code snippet for throw new ArgumentNullException</Description>
<Author>SLaks</Author>
<SnippetTypes>
<SnippetType>Expansion</SnippetType>
<SnippetType>SurroundsWith</SnippetType>
</SnippetTypes>
</Header>
<Snippet>
<Declarations>
<Literal>
<ID>Parameter</ID>
<ToolTip>Paremeter to check for null</ToolTip>
<Default>value</Default>
</Literal>
</Declarations>
<Code Language="csharp"><![CDATA[if ($Parameter$ == null) throw new ArgumentNullException("$Parameter$");
$end$]]>
</Code>
</Snippet>
</CodeSnippet>
</CodeSnippets>
Bạn có thể muốn xem qua Hợp đồng mã nếu bạn cần một cách tốt hơn để đảm bảo rằng bạn không nhận bất kỳ đối tượng rỗng nào làm tham số.
Lợi ích chính là bạn đang rõ ràng với các yêu cầu của phương pháp của bạn ngay từ đầu. Điều này làm cho các nhà phát triển khác làm việc trên mã hiểu rõ rằng việc người gọi gửi giá trị null đến phương thức của bạn thực sự là một lỗi.
Việc kiểm tra cũng sẽ tạm dừng việc thực thi phương thức trước khi bất kỳ mã nào khác thực thi. Điều đó có nghĩa là bạn sẽ không phải lo lắng về việc sửa đổi được thực hiện bằng phương pháp bị bỏ dở.
Nó tiết kiệm một số gỡ lỗi, khi bạn nhấn vào ngoại lệ đó.
ArgumentNullException tuyên bố rõ ràng rằng đó là "s" là null.
Nếu bạn không có kiểm tra đó và để cho mã nổ tung, bạn sẽ nhận được NullReferenceException từ một số dòng không xác định trong phương thức đó. Trong một phiên bản phát hành, bạn không nhận được số dòng!
Mã gốc:
void f(SomeType s)
{
if (s == null)
{
throw new ArgumentNullException("s cannot be null.");
}
// Use s
}
Viết lại nó thành:
void f(SomeType s)
{
if (s == null) throw new ArgumentNullException(nameof(s));
}
[Chỉnh sửa] Lý do để viết lại bằng cách sử dụng nameoflà vì nó cho phép tái cấu trúc dễ dàng hơn. Nếu tên biến của bạn sthay đổi thì các thông báo gỡ lỗi cũng sẽ được cập nhật, trong khi nếu bạn chỉ mã hóa tên của biến thì cuối cùng nó sẽ lỗi thời khi cập nhật theo thời gian. Đó là một thực tiễn tốt được sử dụng trong ngành công nghiệp.
int i = Age ?? 0;
Vì vậy, ví dụ của bạn:
if (age == null || age == 0)
Hoặc là:
if (age.GetValueOrDefault(0) == 0)
Hoặc là:
if ((age ?? 0) == 0)
Hoặc bậc ba:
int i = age.HasValue ? age.Value : 0;