TypeScript Ausrufezeichen: die Non-Null-Assertion (!)

Ein Ausrufezeichen hinter einem Ausdruck, value!, ist der Non-Null-Assertion-Operator. Er entfernt null und undefined aus dem Typ, sodass ein number | undefined als number verwendet werden kann. Er ist ein Versprechen an den Compiler, keine Prüfung: Zur Laufzeit passiert nichts.

const prices = new Map<string, number>([
  ["tea", 2.5],
  ["coffee", 3.2],
]);

const tea = prices.get("tea");         // number | undefined
const coffee = prices.get("coffee")!;  // number

console.log(coffee.toFixed(2)); // 3.20
console.log(tea!.toFixed(2));   // 2.50: ! works on any expression

Ohne das ! ist tea.toFixed(2) der Fehler TS18048, 'tea' is possibly 'undefined'. Mit ihm kompiliert der Code, weil du dem Compiler gesagt hast, dass der Schlüssel existiert.

Was x! zur Laufzeit tut: nichts

Das ! wird aus der Ausgabe entfernt. Das kompilierte JavaScript für prices.get("coffee")! ist einfach prices.get("coffee"). Ist die Assertion falsch, tritt der Fehler später auf, an der ersten Stelle, an der der fehlende Wert verwendet wird:

const prices = new Map<string, number>([["tea", 2.5]]);

try {
  const juice = prices.get("juice")!; // compiles: the ! silences the check
  console.log(juice.toFixed(2));      // TypeError at runtime
} catch (e) {
  console.log((e as Error).message);
}

Das Programm gibt Cannot read properties of undefined (reading 'toFixed') aus. Der Absturz passiert in der Zeile nach dem !, und in echtem Code kann er viel weiter entfernt sein: Das undefined kann in einem Objekt gespeichert werden und in einer anderen Datei explodieren. Diese Entfernung macht ! riskant.

Definite Assignment: let x!: T

Dasselbe Zeichen in einer Deklaration bedeutet etwas Verwandtes. TypeScript verfolgt, ob eine Variable zugewiesen wird, bevor sie gelesen wird, und kann einer Zuweisung in einer anderen Funktion nicht folgen:

// This does not compile: TypeScript cannot see the assignment inside init()
let config: { port: number };

function init() {
  config = { port: 8080 };
}

init();
console.log(config.port);

index.ts(9,13): error TS2454: Variable 'config' is used before being assigned.

let config!: { port: number }; ist eine Definite Assignment Assertion: „Das wird vor jedem Lesen zugewiesen.“ Sie behebt den Fehler, mit demselben Haken wie x!: Wird init() jemals übersprungen, liest das Lesen undefined. Umstrukturieren ist meist besser, zum Beispiel const config = init();, wobei init das Objekt zurückgibt.

Klasseneigenschaften: prop!: T

Mit strictPropertyInitialization (Teil von strict) muss jede Klasseneigenschaft in ihrer Deklaration oder im Konstruktor initialisiert werden. Sonst bekommst du TS2564: Property 'socket' has no initializer and is not definitely assigned in the constructor. Wird eine Eigenschaft später von einer Methode oder einem Framework gesetzt, sagt prop!: T dem Compiler, dass er sie akzeptieren soll:

class Connection {
  url: string;
  socket!: { send(msg: string): string }; // set in open(), not in the constructor

  constructor(url: string) {
    this.url = url;
  }

  open() {
    this.socket = { send: (msg) => `sent "${msg}" to ${this.url}` };
  }
}

const c = new Connection("ws://example.com");
console.log(c.socket);            // undefined: declared but not set yet
c.open();
console.log(c.socket.send("hi")); // sent "hi" to ws://example.com

Das erste console.log zeigt die Lücke: Der Typ sagt, socket sei immer da, aber vor open() ist es undefined. c.socket.send an dieser Stelle aufzurufen kompiliert und wirft. Kann die Eigenschaft wirklich fehlen, deklariere sie als socket?: ... und prüfe sie, oder erzeuge das Objekt im Konstruktor. Der Hauptort, an dem prop! gängige Praxis ist, ist ein Framework, das eine Eigenschaft nach der Konstruktion füllt: @ViewChild(...) child!: ChildDirective in Angular (gesetzt, bevor ngAfterViewInit läuft), oder Entity-Klassen von ORMs, deren Spalten die Bibliothek beim Laden einer Zeile füllt (die Dokumentation von MikroORM schreibt @Property() title!: string).

Sicherere Alternativen

Die meisten ! lassen sich durch etwas ersetzen, das der Compiler prüft, oder durch eine Prüfung, die an der richtigen Stelle laut scheitert:

function must<T>(value: T | null | undefined, what: string): T {
  if (value == null) throw new Error(`missing ${what}`);
  return value;
}

function assertDefined<T>(value: T, what: string): asserts value is NonNullable<T> {
  if (value == null) throw new Error(`missing ${what}`);
}

const env = new Map([["PORT", "8080"]]);

const port = must(env.get("PORT"), "PORT"); // string
console.log(Number(port) + 1);              // 8081

const host = env.get("HOST");
try {
  assertDefined(host, "HOST");
  console.log(host.toUpperCase()); // host is string after the assertion
} catch (e) {
  console.log((e as Error).message); // missing HOST
}

Beide Hilfsfunktionen engen den Typ ein wie !, aber eine falsche Annahme erzeugt missing HOST direkt an Ort und Stelle statt eines TypeError irgendwo anders. assertDefined ist eine Assertion-Funktion (asserts value is ...): Nach dem Aufruf behandelt der Compiler host als string. Weitere Muster unter Type Guards.

Die anderen Ausrufezeichen

! bedeutet je nach Position Verschiedenes:

Nur die ersten beiden werden beim Kompilieren entfernt. !value und !!value laufen zur Laufzeit und geben einen Boolean zurück.