I'm new to typescript and my textbook says:

A non-null assertion should be used only when you know that a null value cannot occur. A runtime error will be caused if you apply the assertion and a null value does occur.

so I write a simple typescript file to verify(with "strictNullChecks": true):

function calculateTax(amount: number, format: boolean): string | number | null {
    if (amount === 0) {
        return null;
    }
    const calcAmount = amount * 1.2;
    return format ? `$${calcAmount.toFixed(2)}` : calcAmount;
}
let taxValue: string | number = calculateTax(0, false)!;

Below is my questions:

Q1- we can see that calculateTax(0, false) will return null, after I ran the program, there is no run time error at all? why the author says there will be run time error?

Q2-I can just rewrite the statement without non-null assertion as:

let taxValue: string | number = calculateTax(0, false);

it has no pilation error and run time error, works perfectly, so what's the point to use non-null assertion?

I'm new to typescript and my textbook says:

A non-null assertion should be used only when you know that a null value cannot occur. A runtime error will be caused if you apply the assertion and a null value does occur.

so I write a simple typescript file to verify(with "strictNullChecks": true):

function calculateTax(amount: number, format: boolean): string | number | null {
    if (amount === 0) {
        return null;
    }
    const calcAmount = amount * 1.2;
    return format ? `$${calcAmount.toFixed(2)}` : calcAmount;
}
let taxValue: string | number = calculateTax(0, false)!;

Below is my questions:

Q1- we can see that calculateTax(0, false) will return null, after I ran the program, there is no run time error at all? why the author says there will be run time error?

Q2-I can just rewrite the statement without non-null assertion as:

let taxValue: string | number = calculateTax(0, false);

it has no pilation error and run time error, works perfectly, so what's the point to use non-null assertion?

• javascript
• typescript

• 2 There will be a runtime error if you do something with the null. TS piles to JS, so naturally you can have nulls and the mere presence of one doesn't cause a problem. But calculateTax(0, false).toString() would result in a TypeError. – VLAZ Commented Sep 16, 2019 at 7:10
• As for Q2 - you could but that can still return null, so it's not just string or number. – VLAZ Commented Sep 16, 2019 at 7:10
• @VLAZ I understand that calculateTax(0, false).toString() would result in a TypeError. So we just need to use typeof to tell, that's exactly my question, what's the point to use non-null assertion if you still need to manually check it? – user11680003 Commented Sep 16, 2019 at 7:21
• 1 Non-null assertions are for when you as a programmer know that you won't get a null but TS cannot figure it out. E.g., you do calculateTax(userInput, false) which could result with null for userInput = 0 but you are actually filtering that value before it gets to that point of the code. TS cannot figure this out (e.g., it doesn't know of your validation logic) but it does know that the result could be null. You, however, know that you won't have userInput = 0 ever, so you can just tell that to TS. – VLAZ Commented Sep 16, 2019 at 7:23

2 Answers 2

I guess you misunderstood what a type assertion does. It's not something that piler ensures, it's a kind of "waiver" you give the piler saying "I hereby renounce the right to have this type checked, I guarantee that it will be X at run-time and I'm responsible for consequences if it is not".

By using the ! assertion you're basically telling the piler "shut up, I know better, this never gonna be null". The piler has no option but to agree with you, but if you don't keep your promise (which you don't), a run time fault is imminent.

Obviously, a type assertion is almost never a good idea. Finally, the whole point of Typescript is to have your types statically checked. Think twice before putting ! or as here and there.

If you run pilation with --strictNullChecks, a pilation error

error TS2531: Object is possibly 'null'.

should be raised. I guess the author intended to state that non-null assertions lead to runtime exception if you continue to use the object that supposedly is non-null.

For example calling a function on taxValue in your example above with the non-null assertion would not warn you that the value might be null but if it is null and you call the function during runtime it will raise an exception.

The non-null assertion can be used for you to remove falsy warning that a knonw-non-null variable whose type could be null can be used as if it were not nullable.