controllo dei parametri di errore nel nodo

Question

Si tratta di un convegno a nodo per passare un parametro di errore per le operazioni asincrone:

async.someMagicalDust(function(callback) { 
    // some asynchronous task 

    // […] 
    callback(); 

}, function(err) { 
    // final callback 

    if(err) throw err;  
    // […] 

}); 

Forse sono troppo ingenuo, ma non sono mai stato un grande fan della notazione if(variable) - Probabilmente ereditato da C, per motivi che have already been discussed many times in the past.

D'altra parte, qualche volta ho incontrato un parametro null e questo controllo errore:

if(typeof err !== 'undefined' && err !== null) 

è un po 'troppo prolisso.

Un'altra soluzione sarebbe quella

if(err != null) 

ma penso che il non-strict check può essere difficile, anche se ritengo che sia normale quando si confrontano con null.

Qual è il modo migliore per verificare i parametri di errore nel nodo?

Answer 1

Utilizzare if(err).

È progettato per essere utilizzato in questo modo. I callback in stile nodo dovrebbero impostare l'errore su un valore non falsi solo in caso di errore effettivo. Non troverai alcun esempio corretto di impostare err a '' o 0 per indicare un errore.

Proprio come YlinaGreed ha notato, se le convenzioni modulo cnahge da null a undefined-0 a forse anche NaN, si è ancora al sicuro. Non sono mai stato colpito da questo avendo usato solo if(err).

D'altra parte, si consiglia di utilizzare coffescript, che si tradurrebbe per voi

unless err? then... 

in

if (typeof err === "undefined" || err === null) { 

imitando il modello più comune.

Alcuni link per corroborare l'approccio if(err):

• https://gist.github.com/klovadis/2548942
• http://caolanmcmahon.com/posts/nodejs_style_and_structure/ (da Caolan McMahon, autore di async)
• http://thenodeway.io/posts/understanding-error-first-callbacks/

La convenzione sembra passare un errore oggetto come primo argomento e null per nessun errore quindi anche se passi un oggetto vuoto, è ancora un errore.

Se si utilizza il framework popolare express, si dovrebbe hanno utilizzato il next richiamata al ritorno dal middleware, che segue la convenzione errback.

Credo che la maggior parte delle persone preferisce più concisa next() di next(null), il che significa che il primo argomento valuterà a undefined piuttosto che null, e questo è certamente l'utilizzo perfettamente normale.

Answer 2

Per me, il modo migliore per gestire l'errore è il "se (err == null)" Questo è l'unico caso io sto usando l'operatore non rigorosa, per questi motivi:

• L'unica over solution che funziona sempre è molto prolisso, come hai detto prima
• Puoi anche controllare solo su "null" o "undefined", ma l'ho fatto una volta, e qualche mese dopo ho aggiornato le mie dipendenze e .. La convenzione è cambiata e il modulo inviava null anziché non definito.

Questo è principalmente un questioni di "convenzione", io ho il mio, e vi certairnly avere il vostro è troppo ... Basta essere attenti a scegliere uno dei due modi "buoni".

Answer 3

La convenzione di callback principale del nodo è passare una funzione con err come primo parametro. Nella mia esperienza è sempre stato sicuro controllare se l'errore è vero - in pratica se il tuo errore risulta nullo quando c'è un errore allora il problema risiede più nell'implementazione. Mi aspetterei sempre che err sia nullo che non si sia verificato alcun errore. Può essere fonte di confusione a causa dell'uso di funzioni separate per errori e successi, qualcosa che è più nello stile di JQuery.Ajax e promesse. Tendo a trovare due richiami per essere un po 'troppo prolisso da chiamare.

Dato il tuo esempio, sembra che tu stia usando la libreria asincrona che è eccellente. Se sto cercando di effettuare una scelta in parallelo questo è come impostare il tutto:

function doAThing(callback) { 
    var err; 

    // do stuff here, maybe fill the err var 

    callback(err); 
} 

function doAsyncThings(callback) { 
    var tasks = [function(done) { // stuff to do in async 
    doAThing(function(err) { 
     done(err); 
    }); 
    }]; 

    async.parallel(tasks, function(err) { // single callback function 
     callback(err); // I send the error back up 
    }); 
} 

noti che invece di buttare l'errore che gorgogliava indietro lungo la catena richiesta. Ci sono alcune istanze che vorrei veramente lanciare un errore dato che stai praticamente dicendo "crash l'intera app".

Trovo che sia più semplice e riduce la quantità di parametri che devi usare per chiamare le tue funzioni. Quando si utilizza questa convenzione tutto si è possibile semplificare semplicemente passando il callback come parametro invece di creare una nuova funzione anonima, in questo modo:

function doAThing(callback) { 
    var err; 

    // do stuff here, maybe fill the err var 

    callback(err); 
} 

function doAsyncThings(callback) { 
    var tasks = [function(done) { // stuff to do in async 
    doAThing(done); 
    }]; 

    async.parallel(tasks, callback); // the error is sent back to the original function 
} 

Trovo che in genere si desidera gestire tali errori nelle funzioni che vengono chiamati. Quindi in questo caso il chiamante di doAsyncThings può controllare se c'è un errore e gestirlo in modo appropriato al proprio ambito (e magari fornire informazioni migliori all'utente se si dice un'API).