-1

Using a website with Javascript as example.

Let's say I have script A which only performs a specific function on page Foo. For example something like sorting elements in a list.

Script A is only added to pages that have a list that needs sorted via javascript.

In the javascript we access the list with document.querySelector('#list'); now because this script is only added to pages I know have the list I feel like it would be safe to just immediately start accessing the children of list to sort. Additionally even if a list is removed for whatever reason the only issue is an error in the console.

Thus my question is should a null check be performed even if I know it will only be used on pages that will not return null?

  • 1
    If you know it can't be null, don't clutter the code with checks because the checks have a cost - increased complexity - and no benefit. – Solomonoff's Secret Jan 11 at 17:51
3

In this case there is no need for a null check. Removing the list is not necessarily the use case I'm thinking about here.

What if a markup error is introduced to the HTML that causes the browser to parse it incorrectly, and the list isn't in the DOM?

Well. I'd say you've got bigger problems than some null checks in JavaScript.

What if someone opens the DOM inspector for the browser, and deletes the element?

Well, I guess you shouldn't do that.

What if some other JavaScript widget accidentally removes the list from the DOM?

I'm willing to bet that defect is what should get fixed, without spending additional time on null checks and error handling for a web page.

Basically, if for some odd reason the list disappears from the screen and you get a null reference error, will the absence of null checks make it harder to debug the problem, and if so, will be it hard enough to justify the extra code?

If it is still easy to debug, then no need for null checks.

If it is harder to debug, but not so hard it makes sense to spend time on this sort of error handling, then there is no need for null checks.

If, on the other hand, you are writing software that controls a robot arm, and a null reference exception causes it to swing around wildly while grasping a car door, then I'd say you better be putting some null checks in there.

But for a web page? Nope. Not worth the time (unless it makes web API calls to control a robot arm grasping a car door, of course. Also I hope you have really good authentication around this web API...).

1

I see three different approaches, depending on your intentions:

  • If you absolutely trust that the list can't be null, there's no need to check.

  • If you just want to prepare for robustness, e.g. not completely crashing in the unlikely event of the list being null, then take a broader approach. Somewhere in your code some exception might arise (your list being null might only be one possibility among hundreds of others). Then find a place surrounding that code where you can plausibly continue (meaning try/catch) instead of crashing. At that place, show an "Oops!" message to the user, and log an error report to your server, including as much information as possible (and acceptable for your user). You typically need at most handful of catch places to achieve that robustness.

  • If you define null to be valid for the list, decide what it means, and implement the correct behaviour wherever you use the list.

From your question, I guess that the second approach might best match your intentions.

You say

...even if a list is removed for whatever reason...

I'd call it a software bug to remove a list from a page where a list is expected. Don't cover that bug by "gracefully" dealing with a deleted list. Make it prominently visible during tests, so it can be fixed instead of creating strange problems later on.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.