Tipi di errore in JavaScript: SyntaxError, TypeError, ReferenceError

Gli errori sono oggetti con un tipo

Quando JavaScript lancia un errore, non ti restituisce una semplice stringa: ti restituisce un oggetto. Quell'oggetto ha un tipo (il suo costruttore) e alcune proprietà standard: name, message e stack.

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

err.name è un'etichetta breve come "TypeError". err.message è la descrizione leggibile. err instanceof TypeError ti dice la classe specifica. Conoscere il tipo è importante: ti dice se il problema è un refuso, un valore sbagliato o codice che non è stato nemmeno interpretato.

Esistono sette tipi di errore predefiniti. Tre li vedrai di continuo, quattro solo ogni tanto.

SyntaxError: il codice non è stato interpretato

Un SyntaxError significa che JavaScript non è riuscito nemmeno a leggere il tuo codice. Non è davvero un errore di runtime: il motore fallisce durante il parsing, prima che venga eseguita una sola riga. Non puoi intercettare con try/catch un SyntaxError nello stesso file, perché l'intero file viene rifiutato.

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

Una parentesi mancante, una virgola di troppo, un return fuori da una funzione: qualsiasi cosa rompa la grammatica lancia questo errore. La soluzione è sempre correggere il sorgente. L'unico caso in cui puoi catturare un SyntaxError è quando il parsing avviene a runtime, come con JSON.parse:

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

JSON.parse riceve una stringa durante l'esecuzione, quindi i suoi errori di sintassi si possono catturare. Quelli nei tuoi file sorgente no.

ReferenceError: quel nome non esiste

Un ReferenceError scatta quando fai riferimento a una variabile che non è stata dichiarata in nessuno scope visibile dal codice corrente.

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

Nove volte su dieci si tratta di un refuso (totl invece di total). Il resto dei casi riguarda lo scope: stai cercando di usare qualcosa dichiarato in un'altra funzione o in un altro modulo.

C'è poi una causa più sottile: la temporal dead zone. Le dichiarazioni let e const esistono dall'inizio del loro blocco, ma non puoi accedervi prima della riga che le dichiara:

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

Quando viene eseguito console.log(x), x è già un binding reale, ma non è ancora stato inizializzato. Da qui il reference error. La soluzione è spostare l'accesso dopo la dichiarazione.

TypeError: il valore aveva la forma sbagliata

Un TypeError significa che un valore esiste, ma non è del genere che l'operazione si aspetta. Chiamare qualcosa che non è una funzione, leggere una proprietà di null o undefined, assegnare un nuovo valore a una const: sono tutti 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')" è probabilmente il messaggio di errore più comune in assoluto in JavaScript. La soluzione è garantire che il valore esista, oppure proteggere l'accesso con l'optional chaining: user?.name.

Altre varianti di 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);
}

Chiamare un numero, riassegnare una const, chiamare un metodo che non esiste: il valore era del tipo sbagliato per quello che gli hai chiesto di fare.

RangeError: il numero è fuori dai limiti

RangeError scatta quando un numero è tecnicamente valido ma fuori dall'intervallo consentito per una specifica operazione.

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);
}

La causa classica è la ricorsione infinita, che fa saltare lo stack delle chiamate:

function recurse() {
    return recurse();
}

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

"Maximum call stack size exceeded" significa quasi sempre che una funzione chiama sé stessa senza un caso base, oppure che due funzioni si chiamano a vicenda in un ciclo.

URIError ed EvalError: quelli rari

URIError arriva dalle funzioni di gestione degli URI (encodeURI, decodeURIComponent e simili) quando ricevono un input malformato:

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

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

EvalError è un residuo del passato. I motori JavaScript moderni non lo lanciano più per nessun motivo: esiste ancora come costruttore per retrocompatibilità. Puoi crearne uno a mano, ma non lo vedrai mai nel codice reale.

La catena di ereditarietà

Tutti questi tipi ereditano da una classe base Error. Questo significa che err instanceof Error è true per ognuno di loro, cosa comoda in un catch generico:

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));
}

Un blocco catch cattura tutto, compresi i valori che non sono errori se qualcuno scrive throw "oops". Per questo l'ultimo ramo è importante. Restringi sempre con instanceof prima di trattare un valore catturato come un oggetto errore.

Lanciare errori di proposito

Puoi lanciare tu stesso uno qualsiasi dei tipi predefiniti quando il tuo codice rileva un problema. Scegli il tipo che corrisponde al fallimento:

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);
}

Far corrispondere il tipo al fallimento non è solo una questione estetica: permette a chi chiama la funzione di scrivere una logica catch mirata invece di analizzare i messaggi di errore.

Classi di errore personalizzate

Quando i tipi predefiniti non vanno bene, estendi 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}`);
    }
}

Due cose da ricordare: chiama super(message) perché la classe base Error venga inizializzata correttamente, e imposta this.name perché i log mostrino l'etichetta giusta. Campi personalizzati come field permettono a chi chiama di reagire a specifici tipi di errore senza dover analizzare stringhe.

Prossimo passo: console e DevTools

Conoscere i tipi di errore è metà del lavoro. L'altra metà è saper leggere uno stack trace e ispezionare lo stato mentre il programma è in esecuzione. Gli strumenti per sviluppatori del browser (e il debugger di Node) trasformano "ha lanciato un errore e non so perché" in pochi secondi di ispezione. È il prossimo argomento.