Ricerca…


Sintassi

  • prova {...} catch (errore) {...}
  • prova {...} alla fine {...}
  • prova {...} catch (errore) {...} alla fine {...}
  • lanciare un nuovo errore ([messaggio]);
  • lancia Errore ([messaggio]);

Osservazioni

try consente di definire un blocco di codice da testare per gli errori mentre è in esecuzione.

catch consente di definire un blocco di codice da eseguire, se si verifica un errore nel blocco try .

ti consente finally di eseguire codice indipendentemente dal risultato. Attenzione però, le istruzioni del flusso di controllo dei blocchi try and catch verranno sospese fino al termine dell'esecuzione del blocco finally.

Interazione con le promesse

6

Le eccezioni sono al codice sincrono quali reiezioni devono garantire un codice asincrono basato su promessa . Se un'eccezione viene lanciata in un gestore di promessa, il suo errore verrà automaticamente catturato e utilizzato per rifiutare la promessa.

Promise.resolve(5)
    .then(result => {
        throw new Error("I don't like five");
    })
    .then(result => {
        console.info("Promise resolved: " + result);
    })
    .catch(error => {
        console.error("Promise rejected: " + error);
    });

Promise rejected: Error: I don't like five
7

La proposta di funzioni asincrone, inaspettata per far parte di ECMAScript 2017, estende questo nella direzione opposta. Se attendi una promessa respinta, il suo errore viene sollevato come eccezione:

async function main() {
  try {
    await Promise.reject(new Error("Invalid something"));
  } catch (error) {
    console.log("Caught error: " + error);
  }
}
main();

Caught error: Invalid something

Oggetti di errore

Gli errori di runtime in JavaScript sono istanze dell'oggetto Error . L'oggetto Error può anche essere utilizzato così com'è oppure come base per le eccezioni definite dall'utente. È possibile lanciare qualsiasi tipo di valore, ad esempio stringhe, ma si consiglia vivamente di utilizzare Error o una delle sue derivate per garantire che le informazioni di debug, come le tracce di stack, siano correttamente conservate.

Il primo parametro del costruttore Error è il messaggio di errore leggibile. Dovresti provare a specificare sempre un messaggio di errore utile su cosa è andato storto, anche se è possibile trovare ulteriori informazioni altrove.

try {
   throw new Error('Useful message');
} catch (error) {
   console.log('Something went wrong! ' + error.message);
}

Ordine delle operazioni più pensieri avanzati

Senza un blocco catch try, le funzioni non definite generano errori e interrompono l'esecuzione:

undefinedFunction("This will not get executed");
console.log("I will never run because of the uncaught error!");

Genera un errore e non esegue la seconda riga:

// Uncaught ReferenceError: undefinedFunction is not defined

Hai bisogno di un blocco catch try, simile ad altre lingue, per assicurarti di rilevare l'errore in modo che il codice possa continuare a essere eseguito:

try {
    undefinedFunction("This will not get executed");
} catch(error) {
    console.log("An error occured!", error);
} finally {
    console.log("The code-block has finished");
}
console.log("I will run because we caught the error!");

Ora abbiamo rilevato l'errore e possiamo essere certi che il nostro codice verrà eseguito

// An error occured! ReferenceError: undefinedFunction is not defined(…)
// The code-block has finished
// I will run because we caught the error!

Cosa succede se si verifica un errore nel nostro blocco di cattura !?

try {
    undefinedFunction("This will not get executed");
} catch(error) {
    otherUndefinedFunction("Uh oh... ");
    console.log("An error occured!", error);
} finally {
    console.log("The code-block has finished");
}
console.log("I won't run because of the uncaught error in the catch block!");

Non elaboreremo il resto del nostro blocco di cattura, e l'esecuzione si arresterà tranne che per il blocco finale.

// The code-block has finished
// Uncaught ReferenceError: otherUndefinedFunction is not defined(…)

Puoi sempre annidare i tuoi blocchi di cattura di prova .. ma non dovresti farlo perché diventerà estremamente disordinato ..

try {
    undefinedFunction("This will not get executed");
} catch(error) {
    try {
        otherUndefinedFunction("Uh oh... ");
    } catch(error2) {
        console.log("Too much nesting is bad for my heart and soul...");
    }
    console.log("An error occured!", error);
} finally {
    console.log("The code-block has finished");
}
console.log("I will run because we caught the error!");

Catturerà tutti gli errori dell'esempio precedente e registrerà quanto segue:

//Too much nesting is bad for my heart and soul...
//An error occured! ReferenceError: undefinedFunction is not defined(…)
//The code-block has finished
//I will run because we caught the error!

Quindi, come possiamo cogliere tutti gli errori !? Per variabili e funzioni non definite: non puoi.

Inoltre, non dovresti racchiudere tutte le variabili e le funzioni in un blocco try / catch, poiché si tratta di semplici esempi che si verificano solo una volta fino a quando non vengono risolti. Tuttavia, per oggetti, funzioni e altre variabili che conosci esistono, ma non sai se le loro proprietà o sub-processi o effetti collaterali esisteranno, o ti aspetti alcuni stati di errore in alcune circostanze, dovresti astrarre la gestione degli errori in qualche modo. Ecco un esempio e un'implementazione molto semplici.

Senza un modo protetto per chiamare metodi di lancio non sicuri o di eccezione:

function foo(a, b, c) {
    console.log(a, b, c);
    throw new Error("custom error!");
}
try {
    foo(1, 2, 3);
} catch(e) { 
    try {
        foo(4, 5, 6); 
    } catch(e2) {
        console.log("We had to nest because there's currently no other way...");
    }
    console.log(e);
}
// 1 2 3
// 4 5 6
// We had to nest because there's currently no other way...
// Error: custom error!(…)

E con protezione:

function foo(a, b, c) {
    console.log(a, b, c);
    throw new Error("custom error!");
}
function protectedFunction(fn, ...args) {
    try {
        fn.apply(this, args);
    } catch (e) {
        console.log("caught error: " + e.name + " -> " + e.message);
    }
}

protectedFunction(foo, 1, 2, 3);
protectedFunction(foo, 4, 5, 6);

// 1 2 3
// caught error: Error -> custom error!
// 4 5 6
// caught error: Error -> custom error!

Rileviamo errori e elaboriamo ancora tutto il codice previsto, anche se con una sintassi leggermente diversa. In entrambi i casi funzionerà, ma mentre costruisci applicazioni più avanzate vorrai iniziare a pensare a come astrarre la gestione degli errori.

Tipi di errore

Esistono sei specifici costruttori di errori di base in JavaScript:

  • EvalError - crea un'istanza che rappresenta un errore che si verifica per quanto riguarda la funzione globale eval() .

  • InternalError : crea un'istanza che rappresenta un errore che si verifica quando viene generato un errore interno nel motore JavaScript. Ad esempio "troppa ricorsione". (Supportato solo da Mozilla Firefox )

  • RangeError : crea un'istanza che rappresenta un errore che si verifica quando una variabile numerica o un parametro non rientra nell'intervallo valido.

  • ReferenceError - crea un'istanza che rappresenta un errore che si verifica durante la dereferenziazione di un riferimento non valido.

  • SyntaxError - crea un'istanza che rappresenta un errore di sintassi che si verifica durante l'analisi del codice in eval() .

  • TypeError : crea un'istanza che rappresenta un errore che si verifica quando una variabile o un parametro non è di un tipo valido.

  • URIError - crea un'istanza che rappresenta un errore che si verifica quando vengono passati parametri non validi encodeURI() o decodeURI() .

Se stai implementando un meccanismo di gestione degli errori, puoi verificare quale tipo di errore stai rilevando dal codice.

try {
    throw new TypeError();
}
catch (e){
    if(e instanceof Error){
        console.log('instance of general Error constructor');
    }

    if(e instanceof TypeError) {
        console.log('type error');
    }
}

In tal caso e sarà un'istanza di TypeError . Tutti i tipi di errore estendono l' Error costruttore di base, quindi è anche un'istanza di Error .

Tenendo questo in mente ci mostra che il controllo e per essere un'istanza di Error è inutile nella maggior parte dei casi.



Modified text is an extract of the original Stack Overflow Documentation
Autorizzato sotto CC BY-SA 3.0
Non affiliato con Stack Overflow