Typy błędów w JavaScript: SyntaxError, TypeError, ReferenceError

Błędy to obiekty z typem

Gdy JavaScript rzuca błąd, nie podaje ci po prostu stringa, tylko obiekt. Ten obiekt ma typ (swój konstruktor) i kilka standardowych właściwości: name, message i stack.

try {
    null.foo;
} catch (err) {
    console.log(err.name);
    console.log(err.message);
    console.log(err instanceof TypeError);
}

err.name to krótka etykieta, np. "TypeError". err.message to czytelny dla człowieka opis. err instanceof TypeError mówi ci, o jaką konkretną klasę chodzi. Znajomość typu ma znaczenie: mówi, czy problemem jest literówka, zła wartość, czy kod, który nawet się nie sparsował.

Wbudowanych typów błędów jest siedem. Trzy zobaczysz bez przerwy, cztery spotkasz od czasu do czasu.

SyntaxError: kod się nie sparsował

SyntaxError oznacza, że JavaScript nie był w stanie nawet przeczytać twojego kodu. To właściwie nie jest błąd czasu wykonania: silnik zawodzi podczas parsowania, zanim wykona się choć jedna linia. Nie da się złapać SyntaxError przez try/catch w tym samym pliku, bo cały plik zostaje odrzucony.

function greet(name {
    return "hi, " + name;
}
// SyntaxError: Unexpected token '{'

Brakujący nawias, zbędny przecinek, return poza funkcją: wszystko, co łamie gramatykę, rzuca ten błąd. Poprawka zawsze polega na naprawieniu kodu źródłowego. Jedyne miejsce, w którym możesz złapać SyntaxError, to parsowanie w czasie wykonania, np. przez JSON.parse:

try {
    JSON.parse("{ not valid json }");
} catch (err) {
    console.log(err.name);
    console.log(err.message);
}

JSON.parse dostaje string w czasie wykonania, więc jego błędy składni da się złapać. Błędów we własnych plikach źródłowych już nie.

ReferenceError: ta nazwa nie istnieje

ReferenceError pojawia się, gdy odwołujesz się do zmiennej, która nie została zadeklarowana w żadnym zakresie widocznym dla bieżącego kodu.

try {
    console.log(totl);
} catch (err) {
    console.log(err.name);
    console.log(err.message);
}

W dziewięćdziesięciu procentach przypadków to literówka (totl zamiast total). Pozostałe dziesięć procent to zakres: próbujesz użyć czegoś zadeklarowanego w innej funkcji albo module.

Jest też jedna subtelniejsza przyczyna: temporal dead zone. Deklaracje let i const istnieją od początku swojego bloku, ale nie możesz się do nich odwołać przed linią, która je deklaruje:

try {
    console.log(x);
    let x = 5;
} catch (err) {
    console.log(err.name, err.message);
}

x jest prawdziwym wiązaniem w chwili, gdy wykonuje się console.log(x), ale nie zostało jeszcze zainicjalizowane. Stąd błąd odwołania. Poprawka to przeniesienie odwołania poniżej deklaracji.

TypeError: wartość miała zły kształt

TypeError oznacza, że wartość istnieje, ale nie jest tym, czego oczekuje operacja. Wywołanie czegoś, co nie jest funkcją, odczyt właściwości null lub undefined, przypisanie do const: to wszystko TypeError.

const user = null;

try {
    console.log(user.name);
} catch (err) {
    console.log(err.name);
    console.log(err.message);
}

„Cannot read properties of null (reading 'name')” to prawdopodobnie najczęstszy komunikat błędu w całym JavaScript. Poprawka to albo zagwarantowanie, że wartość istnieje, albo zabezpieczenie odwołania przez optional chaining: user?.name.

Inne odmiany TypeError:

const PI = 3.14;

try {
    const notAFunction = 42;
    notAFunction();
} catch (err) {
    console.log(err.message);
}

try {
    PI = 3.14159;
} catch (err) {
    console.log(err.message);
}

Wywołanie liczby, ponowne przypisanie const, wywołanie nieistniejącej metody: wartość miała zły typ do tego, o co ją poproszono.

RangeError: liczba poza zakresem

RangeError pojawia się, gdy liczba jest technicznie poprawna, ale wykracza poza dozwolony zakres danej operacji.

try {
    const arr = new Array(-1);
} catch (err) {
    console.log(err.name, err.message);
}

try {
    (1.5).toFixed(200);
} catch (err) {
    console.log(err.name, err.message);
}

Klasycznym źródłem jest nieskończona rekurencja, która przepełnia stos wywołań:

function recurse() {
    return recurse();
}

try {
    recurse();
} catch (err) {
    console.log(err.name);
    console.log(err.message);
}

„Maximum call stack size exceeded” prawie zawsze znaczy, że funkcja wywołuje samą siebie bez warunku bazowego albo że dwie funkcje wywołują się nawzajem w pętli.

URIError i EvalError: te rzadkie

URIError pochodzi z funkcji obsługujących URI (encodeURI, decodeURIComponent i spółka), gdy dostaną niepoprawne dane wejściowe:

try {
    decodeURIComponent("%");
} catch (err) {
    console.log(err.name, err.message);
}

try {
    decodeURIComponent("%E0%A4%A");
} catch (err) {
    console.log(err.name, err.message);
}

EvalError to relikt. Nowoczesne silniki JavaScript w praktyce go nie rzucają: nadal istnieje jako konstruktor dla zgodności wstecznej. Możesz utworzyć go ręcznie, ale w prawdziwym kodzie go nie zobaczysz.

Łańcuch dziedziczenia

Wszystkie te typy dziedziczą po bazowym Error. Oznacza to, że err instanceof Error daje true dla każdego z nich, co przydaje się w ogólnym bloku catch:

function classify(err) {
    if (err instanceof TypeError) return "bad value";
    if (err instanceof ReferenceError) return "missing name";
    if (err instanceof RangeError) return "out of range";
    if (err instanceof Error) return "some other error";
    return "not an error at all";
}

try {
    null.foo;
} catch (err) {
    console.log(classify(err));
}

Blok catch łapie wszystko, także wartości niebędące błędami, jeśli ktoś napisze throw "oops". Ta ostatnia gałąź ma znaczenie. Zawsze zawężaj przez instanceof, zanim potraktujesz złapaną wartość jak obiekt błędu.

Celowe tworzenie błędów

Gdy twój kod wykryje problem, możesz sam rzucić dowolny z wbudowanych typów. Wybierz typ, który pasuje do awarii:

function setAge(age) {
    if (typeof age !== "number") {
        throw new TypeError("age must be a number");
    }
    if (age < 0 || age > 150) {
        throw new RangeError("age must be between 0 and 150");
    }
    return age;
}

try {
    setAge("thirty");
} catch (err) {
    console.log(err.name, err.message);
}

Dopasowanie typu do awarii to nie tylko kosmetyka: pozwala kodowi wywołującemu pisać celowaną logikę catch zamiast parsować komunikaty błędów.

Własne klasy błędów

Gdy wbudowane typy nie pasują, rozszerz Error:

class ValidationError extends Error {
    constructor(message, field) {
        super(message);
        this.name = "ValidationError";
        this.field = field;
    }
}

try {
    throw new ValidationError("email is required", "email");
} catch (err) {
    if (err instanceof ValidationError) {
        console.log(`[${err.field}] ${err.message}`);
    }
}

Pamiętaj o dwóch rzeczach: wywołaj super(message), żeby bazowy Error został poprawnie skonfigurowany, i ustaw this.name, żeby logi pokazywały właściwą etykietę. Własne pola, takie jak field, pozwalają kodowi wywołującemu reagować na konkretne rodzaje awarii bez parsowania stringów.

Dalej: konsola i DevTools

Znajomość typów błędów to połowa sukcesu. Druga połowa to czytanie stack trace'a i podglądanie stanu w trakcie działania programu. Narzędzia deweloperskie przeglądarki (i debugger Node) zamieniają „rzuciło błędem i nie wiem dlaczego” w kilka sekund inspekcji. O tym jest następna strona.