型定義でUndifinedが許容されているものの、Undefinedでない確証のある値のエラーを抑制する方法について

Question

TypeScriptにおいて、型定義でUndefinedが許容されているものの、Undefinedでない確証がある値のエラーを抑制する適切な方法を調べています。
過去にズバリな質問がありましたが、こちらのベストアンサーではHOGE.bar?.length ?? 1という方法が使われています。
理屈はわかるのですが、これを使うのであればHOGE!.barでいいのでは？という気がしてなりません。
前述の方法を使うメリットは何なのでしょうか。
コンパイラに安全だと明示するより、自然な形で推論されたほうがいいということでしょうか。

追記

タイトル、説明文が分り辛かったので修正しました。

Answer 1

ありえない事態だから実行時エラーになってほしい時に使うのがHOGE!.bar

ありえる事態で、その時は実行時エラーにせずに、ある(デフォルトの)値で動作してもらってかまわない時に使うのがHOGE.bar?.length ?? 1

Comments

[toromou]

ご回答ありがとうございます。

失礼ながらご確認させていただきますが、
"ありえない事態だからエラーになってほしい時に使うのがHOGE!.bar"というのは
"Undefinedでない確証があるのでエラーにしたくない時に使う"という解釈でよろしいですか。

[quickquip]

ちょっと書き換えました。

"Undefinedでない確証があるのでエラーにしたくない時に使う"のエラーはコンパイルエラーですよね。
回答の"エラーになってほしい"は実行時エラーの話でしたので、そこを書きました。

プログラマは"Undefinedでない確証がある"けれども、型チェック的には"Undefinedである可能性がある"場合、プログラマ側の"Undefinedでない確証"は単なる信義でしかありません。
プログラマにどれほどの確証があったって、バグや見落としがあったら、簡単に覆る話です。

バグや見落としで実行時にもしUndefinedが来たらどうするべきか? で使い分けます、という回答です。

[toromou]

なるほど、コンパイルエラーと実行時のエラーでごっちゃになっていました。失礼しました。

今回はjQueryで要素を取得した際を想定していたのですが、何らかのミスで指定した要素が存在しなくなる場合もありえるので、それをケアしたほうがいいのかもしれませんね。

大変わかりやすい説明ありがとうございました。

Answer 2

前述の方法を使うメリットは何なのでしょうか。

本当にundefinedが来た場合も問題なく動作します。

Comments

[toromou]

ご回答ありがとうございます。

言葉足らずでしたが、型定義でundefinedが許容されているものの、undefinedでないことが確定的な値の取り扱いについてです。
その場合は"HOGE!.bar"でも問題ないのでしょうか。