Best practice NodeJS: errori per il controllo del flusso?

Question

In Node.js, dovrei usare gli errori per il controllo di flusso, o dovrei li uso più come eccezioni?

sto scrivendo un controller di autenticazione e di alcuni test di unità in Sails.js, e attualmente, i miei assegni metodo di registrazione per vedere se un utente con lo stesso nome utente esiste. Se un utente è già esistente con il nome utente, il mio metodo modello chiama i suoi argomenti di callback con un nuovo oggetto Error, in questo modo:

Modello:

exists: function (options, cb) { 
    User.findOne({ 
     where: { username: typeof options === 'Object' && options.username ? options.username : options }, 
    }).exec(function (err, user) { 
     if (err) return cb(err); 
     if (user) return cb(new Error("A user with that username already exists.")); 
     cb(null, !!user); 
    }); 
}, 

Controller:

User.exists(req.body.user.username, function (err, exists) { 
    if (err) { 
    console.log("error: ", err); 
    return res.status(409).json({ 
     message: err 
    });  
    } 

    User.create(req.user).then(function (data) { 
    res.status(201).json({ 
     user: data 
    }); 
    }); 
}); 

È questo il migliore pratica? Non sono sicuro che le convenzioni sul nodo favoriscano gli errori per casi eccezionali o per il controllo del flusso. Penso che dovrei riscriverlo, ma voglio conoscere le convenzioni prima di farlo. Penso di aver visto alcuni esempi scritti in questo modo su Sails. Grazie!

Answer 1

La risposta di cui sopra è un bene per espresso, ma in controllori Vele non si dovrebbe essere chiamata next; la migliore pratica è di restituire sempre una risposta. Nella maggior parte dei casi, il codice di Sails non vedrà nemmeno next come argomento per una funzione di azione del controller. Inoltre, Sails viene fornito con default response methods incorporato nell'oggetto res, ad esempio res.serverError e res.badRequest, nonché res.negotiate che tenterà di indirizzare l'errore al gestore appropriato per te in base al codice di stato. Così il vostro esempio può essere ottimizzato come:

Modello:

exists: function (options, cb) { 
    User.findOne({ 
     where: { username: typeof options === 'Object' && options.username ? options.username : options }, 
    }).exec(function (err, user) { 
     // res.negotiate will default to a 500 server error 
     if (err) return cb(err); 
     // res.negotiate will just output the status code and error object 
     // as JSON for codes between 400 and 500, unless you 
     // provide a custom view as api/responses/badRequest.ejs 
     if (user) return cb({ 
      status: 409, 
      message: "A user with that username already exists." 
     }); 
     cb(null, !!user); 
    }); 
}, 

Controller:

User.exists(req.body.user.username, function (err, exists) { 
    // Let Sails handle those errors for you 
    if (err) {return res.negotiate(err);} 

    User.create(req.user).then(function (data) { 
    res.status(201).json({ 
     user: data 
    }); 
    }); 
}); 

Answer 2

nodo (o Javascript davvero) può generare errori sulle eccezioni utilizzando la parola chiave throw:

if (something_went_wrong) { 
    throw new Error('Doh!'); 
} 

è possibile anche aggiungere ulteriori parametri per l'oggetto Errore di default per dare significato più semantica per i vostri errori nel programma . Detto questo, non si vorrebbe lanciare un errore nel gestore di percorso perché ciò causerebbe il blocco del processo e del server.

Quando si utilizza i gestori di itinerari in Sails (o esprimere in realtà), è sicuramente dovrebbe verificare il tipo di errore e rispondere al client di conseguenza.

// -- Route handler 
app.get('/something', function (req, res, next) { 

    DB.create({ username: 'user' }, function (err, docs) { 

    if (err) { 

     // This checks to see if we have a unique error from MongoDB 
     // and send the appropriate response to the client 
     if (err.code === 11000 || error.code === 11001) { 
     return res.send(409); // or return res.json(409, {message: "User exists"}); 
     } 

     // Any other error type is assumed to be an internal error so we pass it 
     // down the chain to the error handler middleware 
     return next(err); 

    } 

    // This is a client error, not an internal error so we respond to the client 
    // with the appropriate client error type 
    if (docs.length === 0) return res.send(404); 

    if (user.notAuthorized) return res.send(403); 

    res.send('All Good'); 

    }); 

}); 

noti che nel caso in cui il DB risponde con un errore interno, si passa alla funzione next() captata gestendo errore middleware lungo la catena. Qualsiasi middleware con una parentesi di 4 è definito come middleware di gestione degli errori. Sails ha probabilmente qualche gestore di errore di default, ma probabilmente si può anche ignorare che - è necessario controllare i documenti appropriati per queste informazioni come io preferisco il controllo ci guadagno utilizzando espresso solo.