Stringhe di lancio anziché errori

Dal momento che possiamo lanciare qualsiasi cosa con la parola chiave throw in Javascript, non possiamo semplicemente lanciare direttamente una stringa di messaggi di errore?

Qualcuno sa qualcosa in questo?

Permettetemi di aggiungere un po ‘di background a questo: Molto spesso, nel mondo JavaScript, le persone fanno affidamento sul controllo dei parametri piuttosto che sull’uso del meccanismo try-catch, quindi ha senso lanciare solo errori fatali. Tuttavia, per essere in grado di catturare alcuni errori di sistema, devo usare una class diversa per i miei errori e invece di creare una sottoclass di Error, penso che dovrei usare String.

Va bene buttare tutto ciò che ti piace, ma tieni presente che se la cattura è al di fuori del tuo codice, potrebbe aspettarsi un’istanza di errore completa e non una stringa semplice.

Sì, puoi lanciare altri valori , ma non è una buona pratica .

Qualcuno sa qualcosa in questo?

Una stringa non è un object di errore e non fornisce alcuna informazione di debug utile. Devtools si basa su questo, come il file e la linea in cui è stato creato l’errore, lo stacktrace in corrispondenza della posizione di throw ecc., Disponibili come proprietà sugli oggetti Error .

Ogni volta che pensi di lanciare un valore di stringa primitivo, lancia invece un new Error("") .

Puoi mandare errori con i messaggi, lo sai.

 try { throw new Error("This is an error"); } catch (e) { alert(e.message); // This is an error } 

Ma puoi effettivamente lanciare le stringhe:

 try { throw "This is an error"; } catch (e) { alert(e); // This is an error } 

Come altri hanno menzionato sopra, se non stai lanciando un object Error, allora devi provare / catturare i blocchi per intrappolare questi oggetti e gestirli in modo appropriato oppure essere in un mondo di dolore per il debug.

Tuttavia, quando si tratta di lanciare Errori per scopi di gestione non errori come il controllo del stream del programma, questo può essere un modo utile per utilizzare il throw senza un errore.

Quando si usano i lanci per controllare il stream del programma, può essere inefficiente in qualsiasi linguaggio, dato che il runtime spesso esegue un notevole lavoro di sollevamento per scaricare le informazioni sullo stack delle chiamate e serializzare i dati in modo che siano disponibili per l’ambito di applicazione dell’utente. Evitando la creazione di errori, è ansible evitare questo colpo di prestazioni. La chiave è che devi avere un gestore dello stack di chiamate che sappia come gestire questa situazione. Ad esempio, se si throw {isHardStop: true, stopCode: SOME_CODE} e si progettano i gestori per rilevarlo, si potrebbe essere in grado di appiattire parte del codice o scegliere una syntax più pulita.

Il tuo gestore di questo caso ladder potrebbe essere strutturato come:

 try { ... } catch(thr) { if(!thr){ // Is not Error or Json - Handle accordingly } else if(thr.isHardStop){ // Handle the stop } else { // Most likely a real error. Handle accordingly } }