Tôi muốn có một cách để có được cảnh báo khi một tham chiếu đối tượng có khả năng có thể ném một ngoại lệ tham chiếu Null, để tôi có thể viết mã phòng thủ cho chúng.Xác minh mã tĩnh cho các tham chiếu đối tượng rỗng có sẵn có sẵn không?
Tôi đã xem xét Resharper, nhưng không thấy bất cứ điều gì ở đó hoàn thành điều này.
Hợp đồng mã có thể là không bắt đầu; ứng dụng này khá lớn và được viết bằng .NET 3.5, trước khi các Hợp đồng Mã trở nên chính thức có sẵn.
Tính năng chia sẻ lại thực tế thực hiện được điều gì đó như thế này. NullReferenceExpections có thể được đánh dấu trong IDE màu xanh lam, với các chú giải công cụ khi bạn di chuột qua chúng.
Resharper sau đó theo dõi các lỗi tiềm ẩn và cảnh báo trong cửa sổ riêng kết quả kiểm tra của nó (tách biệt khỏi các lỗi biên dịch Visual Studio và cảnh báo).
Chúng có xuất hiện trong danh sách cảnh báo phân tích không? Có thể họ đang bị chôn vùi trong một biển cảnh báo khác. –
Ồ, tôi hiểu ý của bạn là gì. Chúng sẽ không xuất hiện trong Danh sách lỗi VS; Resharper duy trì cửa sổ riêng để điều hướng và theo dõi các vấn đề về mã. Cập nhật câu trả lời của tôi cho phù hợp. – raveturned
@RobertHarvey bạn đã sử dụng ReSharper chưa? Tôi vừa thử phiên bản thử nghiệm, để xem liệu nó có chọn một vấn đề tương tự null không, nhưng theo mặc định nó đã cho tôi một vài nghìn cảnh báo/lỗi cho giải pháp, rất nhiều trong số đó tôi không quan tâm đến. – Stijn
Nói chung, trừ khi bạn khởi tạo một đối tượng, Nó có thể luôn luôn có khả năng ném một tham chiếu đối tượng null, ít nhất là như xa như các trình biên dịch là có liên quan.
để thuật toán kiểm tra xem tham chiếu đến đối tượng có thể rỗng hay không, nó sẽ phải đi qua mọi đường dẫn có thể mà chương trình của bạn có thể thực hiện và bao gồm đường dẫn trong bất kỳ thư viện bên ngoài nào bạn có thể đang sử dụng. Ngay cả đối với các chương trình đơn giản nhất, thuật toán như vậy sẽ giết hiệu suất của trình biên dịch của bạn.
Vâng, nó không nhất thiết phải kiểm tra * mỗi * thời gian tôi biên dịch. Chủ yếu, tôi đang tìm kiếm các ngoại lệ "cơ hội đầu tiên", không phải tình huống mà một đối tượng được khởi tạo, nhưng có thể được đặt thành null sau đó (tôi hiếm khi, nếu có, làm điều đó). –
Tôi chống lại ý tưởng bảo vệ một cách mù quáng đối với null cho từng trường có sẵn trong mã và bên trong mỗi phương thức.
sau đây giúp tôi quyết định về nơi để kiểm tra đối với các giá trị null:
1- Ai sẽ gọi phương pháp của bạn?
Nếu phương thức là riêng tư và bạn có quyền kiểm soát cách thức truy cập, tôi không thấy nó có ý nghĩa để bảo vệ chống lại kiểm tra rỗng trừ khi nó là một phần của logic của phương thức để mong đợi giá trị null. Nếu một phương pháp được tiếp xúc với công chúng (Chẳng hạn như một API), thì tất nhiên kiểm tra null phải là một mối quan tâm lớn.
2- Phần mềm thiết kế:
ảnh bạn đã được gọi method1(fromAnimalToString(animal)); và vì một lý do fromAnimalToString() không bao giờ trả về null (Mặc dù có thể trả về một chuỗi rỗng thay vì).
Sau đó, trong trường hợp này, nó sẽ không làm cho tinh thần để kiểm tra animal != null trong method1() 's cơ thể
3 Kiểm tra:
Trong công nghệ phần mềm, đó là hầu như không thể kiểm tra tất cả các tình huống có thể là có thể bao giờ hết thi hành. Tuy nhiên, kiểm tra các kịch bản bình thường và thay thế và đảm bảo luồng như mong đợi.
Tôi hỏi vì tôi đã phát hành dự án một vài lần để thử nghiệm và các ngoại lệ tham chiếu null đã xuất hiện không rõ ràng trong thử nghiệm phát triển của tôi. –
Tôi nghĩ trong một môi trường lý tưởng, các nhà phát triển cố gắng hết sức để giảm thiểu sự xuất hiện lỗi. Trong trường hợp hệ thống phức tạp, đó là công việc của QA để cố gắng tạo ra các kịch bản mà các nhà phát triển không nghĩ đến để các kịch bản thay thế có thể được tìm thấy trong pha QA có thể dẫn đến NullPointerExceptions. Trong những trường hợp như vậy, nó có thể không đủ để kiểm tra chống lại null, nhưng cũng phải thực hiện các biện pháp lô-gic thích hợp dựa trên những gì đã gây ra tham số là null. – SiN
Sẽ không dễ dàng hơn khi chỉ kiểm tra xem tham chiếu đến đối tượng có phải là 'null' không? Bạn cũng có thể đi một tuyến đường khác và đảm bảo đối tượng bạn sử dụng, không thể là rỗng. –
Đối với tham chiếu * mọi * đối tượng? : o Một số trong số chúng sẽ không bao giờ rỗng (chúng được đặt trong hàm tạo). –
Thậm chí nếu bạn không sử dụng các Hợp đồng Mã, bạn nên viết các điều khoản bảo vệ ở đầu các phương thức của mình. – jason