Najlepsze praktyki NodeJS: Błędy kontroli przepływu?

Question

W pliku Node.js powinienem użyć błędów do sterowania przepływem lub czy powinienem używać ich bardziej jak wyjątków?

Piszę kontroler uwierzytelniania i niektóre testy jednostkowe w Sails.js, a obecnie moja metoda rejestracji sprawdza, czy istnieje użytkownik o tej samej nazwie użytkownika. Jeśli użytkownik już istnieje z nazwą użytkownika, moja metoda Model nazywa swoje argumenty wywołania zwrotnego z nowego obiektu Error tak:

Model:

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

Kontroler:

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

Jest to najlepszy ćwiczyć? Nie jestem pewien, czy konwencje węzłów faworyzują błędy w wyjątkowych przypadkach lub kontroli przepływu. Myślę, że powinienem to przerobić, ale zanim to zrobię, chcę poznać konwencje. Myślę, że widziałem kilka przykładów napisanych w ten sposób w Żagle. Dzięki!

Answer 1

Powyższa odpowiedź jest dobra dla Express, ale w kontrolerach Sails nie powinieneś dzwonić pod numer next; najlepszą praktyką jest zawsze zwracać odpowiedź. W większości przykładowych kodów Żagli nie zobaczysz nawet next jako argumentu funkcji kontrolera akcji. Zauważ też, że Sails ma wbudowany jakiś obiekt default response methods wbudowany bezpośrednio w obiekt res, taki jak res.serverError i res.badRequest, a także res.negotiate, który spróbuje skierować błąd do odpowiedniego programu obsługi na podstawie kodu statusu. Więc Przykładem mogą być manipulowane jako:

Model:

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

Kontroler:

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

węzła (lub Javascript naprawdę) może rzucać błędy na wyjątki za pomocą słowa kluczowego throw:

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

Można również dodać dodatkowe parametry do obiektu domyślnego Error dać bardziej znaczenie semantyczne do błędów w programie . Po tym, nie chciałbyś rzucić błędu w obsłudze trasy, ponieważ spowodowałoby to awarię procesu i twojego serwera.

Podczas korzystania z funkcji obsługi tras w Sails (lub wyrażania naprawdę), na pewno powinieneś sprawdzić typ błędu i odpowiednio zareagować na klienta.

// -- 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'); 

    }); 

}); 

zauważyć, że w przypadku, DB odpowiada błędem wewnętrznego, przechodzimy do funkcji next() który jest odbierany przez obsługę błędów pośredniej w łańcuchu. Każde oprogramowanie pośrednie o wartości 4 jest zdefiniowane jako oprogramowanie pośredniczące do obsługi błędów. Żagle prawdopodobnie zawierają pewną domyślną procedurę obsługi błędów, ale prawdopodobnie możesz ją również przesłonić - musisz sprawdzić odpowiednie dokumenty, aby uzyskać te informacje, ponieważ preferuję kontrolę, którą uzyskuję za pomocą samego Expressa.