2013-01-17 21 views
6

Tôi gặp vấn đề này khi biến bị thiếu trường và người dùng nhận thấy cảnh báo rằng biến này hoặc biến đó không có thuộc tính này hoặc thuộc tính đó. Trong trường hợp đơn giản, nó rất thẳng về phía trước.Có bao nhiêu kiểm tra đối với null là thích hợp?

if(field) 
    doSomething(field.subField); 

Tuy nhiên, trong các trường hợp thực nghiệm, tôi thấy mình bị kiểm tra quá mức vô lý.

if(!data 
    || !data.records 
    || !data.records[0] 
    || !data.records[0].field 
    || !data.records[0].field.id) 
    return null; 
doSomething(data); 

Ý tôi là, điều này có vẻ như tôi là thợ sửa ống nước chứ không phải nhà phát triển. Vì vậy, tôi có một cảm giác rất mạnh mẽ rằng kiểm tra của tôi, trong khi đủ, có thể là một chút quá-quá-overkill. Có một quy ước nào trong JS về thời điểm thực hiện kiểm tra không?

+3

Nếu bạn cần thực hiện việc này liên tục, mã của bạn có thể có nhiều vấn đề hơn bạn nghĩ. – Prinzhorn

+4

Có thư viện có thể trợ giúp: https://github.com/jclem/steeltoe – epascarello

+2

Cách sử dụng ['try/catch'] (https://developer.mozilla.org/en-US/docs/JavaScript /Reference/Statements/try...catch) thay thế? – Blazemonger

Trả lời

6

Tôi sẽ chỉ đưa ra một ý kiến ​​gây tranh cãi.

Trong JavaScript, đừng bận tâm kiểm tra các giá trị null ở những nơi điều này thực tế không nên xảy ra. Nói cách khác, ý tưởng của bạn về việc kiểm tra từng thuộc tính lồng nhau cho null là một chút quá mức cần thiết, và chỉ phục vụ làm phức tạp kịch bản của bạn.

Theo kinh nghiệm của tôi, tôi đã học được cách chỉ để cho lỗi tập lệnh xảy ra. Điều này có phần phản trực giác đối với người viết mã C hoặc mã cơ sở dữ liệu, trong đó null không được giải quyết có thể làm hỏng máy chủ hoặc dữ liệu bị hỏng, tuy nhiên trong thế giới tập lệnh, tốt hơn để tìm hiểu về lỗi của bạn sớm hơn sau này. Nếu trang của bạn tiếp tục tải mà không có dấu hiệu cho thấy có điều gì đó bất ngờ xảy ra, nó sẽ tự biểu hiện dưới dạng các lỗi lạ sau này khi người dùng nhấp vào nút hoặc gửi biểu mẫu.

Lời khuyên của tôi:

Kiểm tra cho nullchỉ nếu bạn sẵn sàng để làm điều gì đó về nó. Nếu bạn có dịch vụ web có thể trả lại số null nếu có sự cố, hãy kiểm tra và hiển thị thông báo lỗi. Nếu bạn lấy lại một giá trị không null, giả sử nó là một giá trị hợp lệ và tiếp tục. Không có lý do để xả rác toàn bộ kịch bản của bạn với kiểm tra null mà sẽ không thực sự mang lại bất kỳ lợi ích thực sự cho chương trình của bạn.

+0

Vấn đề phát sinh khi khách hàng bị bệnh và mệt mỏi khi nhận được thông báo lỗi và đánh giá từng thông báo như kết thúc của thế giới. Bây giờ, tôi đã lấy mã của người khác vì vậy tôi sẽ phải rời khỏi với hằng số "và có một lỗi một lần nữa" -cloud trên đầu của tôi. nói chung, tuy nhiên, tôi thích suy nghĩ của bạn. Tôi có lẽ sẽ chỉ cần ném trong một thử/bắt và báo cáo các lỗi cho tôi chỉ, sparing người dùng khỏi bị whacked với các thông báo lỗi. Cảm ơn! –

+0

Hầu hết các trình duyệt đều hỗ trợ sự kiện 'window.onerror', vì vậy bạn có thể bẫy điều này và đăng nhập một cách lặng lẽ. –

+0

Không biết về điều đó. Bạn có nghĩa là tôi có thể đi 'window.onerror = function() {...}' ** bên trong ** 'window.onload' method ?! Hoặc nó nên được đặt trên cùng một cấp độ, song song với nó? Và nó được đảm bảo để nắm bắt tất cả các lỗi hoặc cần tôi vẫn sử dụng * try-catch *? –

2

Thông thường bạn sẽ đảm bảo rằng nếu một đối tượng tồn tại, nó luôn có một tập hợp các thuộc tính cơ bản mà làm cho nó có thể sử dụng được.

Ví dụ: nếu biến số data có giá trị, nó sẽ là đối tượng có thuộc tính luôn là một mảng, ngay cả khi nó trống. Nếu mảng chứa bất kỳ thứ gì, nó phải luôn là đối tượng có thuộc tính field, là đối tượng luôn có số lượng id. Điều đó sẽ cắt giảm chi phiếu thành:

if (!data || data.records.length == 0) { 
    return null; 
} 
+0

Tôi thích ý tưởng. Tuy nhiên, như tôi đã nhận xét dưới đây, tôi đã có niềm vui khi tiếp quản dự án sau khi một coder ít hiểu biết hơn và cusomter không sẵn sàng trả tiền cho một tái phát triển. Họ chỉ trả tiền cho chúng tôi để "sửa chữa và vá". Trong hồi tưởng, tôi không nên đồng ý với dự án nhưng tôi đã nghĩ "hey, nó chỉ là JS, làm thế nào khó có thể được để thực hiện một số sửa lỗi". Bây giờ tôi đang đứng đây giống như một ass ... –

+0

Javascript, theo kinh nghiệm của tôi, là môi trường dễ bị xâm nhập nhất, mã điên, tính năng thiếu sót và nếu khóa học ... rất khó gỡ lỗi. – vtortola

+0

Cách tiếp cận này sẽ gây ra lỗi vô ích nếu 'bản ghi' không xác định. Nếu bạn thực sự cần phải nắm bắt tất cả các lỗi sử dụng một 'try/catch'. –

Các vấn đề liên quan