Object is possibly undefined VS Null Assertion Operator => What is the correct way to use?

Question

I have a code example below and at line const cars = x.cars.filter() i am getting an error object is possibly undefined for x.cars. To overcome this issue i have added an if check like if(x.cars). By adding this i have issue with code coverage karma unit testing for this code. So i researched and found there is an Null assertion operator to overcome this typescript compiler issue. Is it ok to use Null assertion operator in this scenario or is there anything else i need to take into consideration ?

this.carOptions$().pipe(
  map((result: any): string => {
    return result
      .filter(x => x.selected)
      .map(x => {
        if (x.cars) { //added this condition to overcome object is possibly undefined error
          const cars = x.cars
            .filter(x => x.selected)
            .map(x => x.name)
            .join(',');
          return `${x.name}~${cars}`;
        }
      })
  })
).subscribe(result => {
  this.result = result;
});

Planning to use Null Assertion Operator as below

 const cars = x.cars!
            .filter(x => x.selected)
            .map(x => x.name)
            .join(',');
          return `${x.name}~${cars}`;

Your code coverage for tests will be the same after nulll assertion opertator. The null assertion operator just prevent the compiler from complaining. So, shortly, it's best to use it sparingly. But, if other tests somewhere tells you you are more or less certain that `cars` is properly initialized and will never be null, that's possibility. — Pac0, Mar 24 '20 at 09:51
without null assertion operator i am not able to meet the threshold of 90% for branches, but when i remove if condition and add null assertion operator i am able to meet the threshold — Deadpool_er, Mar 24 '20 at 09:53
the threshold is some arbitrary guideline, within the limit of the code anaalyzers can do. In both cases, if `x.cars` is `null`, your code will crash the same way, though you meet your treshold apparently in one case. So it's more "cosmetic" ("oh, let's hide this potential bug from the analyzer, so we meet our treshold!") than actually better coding practice here. — Pac0, Mar 24 '20 at 09:55

Pac0 · Accepted Answer · 2020-03-26T00:43:50.520

Improvement of test code coverage after you use !. operator is a lie.

I don't think it is good practice. It may be useful. It may fit your case (if somehow you are completely sure that the base object is never null), but please don't consider it as a silver bullet.

Why isn't it a good practice? Because if the object is null/undefined, your code will break exactly the same way as if you didn't use this operator. But the compiler is just unable to complain, as is your test-cover tool analyzer.

Relevant Q&A : Typescript the safe navigation operator ( ?. ) or (!.) and null property paths

In a sense, your code is a bit simpler with the null asserting operator. You skipped the if. But if cars.x is null, the code with the if doesn't throw an error, whilst the other does. Be aware of this.

Object is possibly undefined VS Null Assertion Operator => What is the correct way to use?

1 Answers1