Je viens de commencer à essayer node.js il y a quelques jours. J'ai réalisé que le nœud est terminé chaque fois que j'ai une exception non gérée dans mon programme. Ceci est différent du conteneur de serveur normal auquel j'ai été exposé, où seul le thread de travail meurt lorsque des exceptions non gérées se produisent et le conteneur serait toujours en mesure de recevoir la demande. Cela soulève quelques questions:

• Est-ce process.on('uncaughtException')le seul moyen efficace de s'en prémunir?
• Attrapera-t-il également process.on('uncaughtException')l'exception non gérée lors de l'exécution des processus asynchrones?
• Existe-t-il un module déjà construit (comme l'envoi d'e-mails ou l'écriture dans un fichier) que je pourrais exploiter dans le cas d'exceptions non interceptées?

J'apprécierais tout pointeur / article qui me montrerait les meilleures pratiques courantes pour gérer les exceptions non capturées dans node.js

Mise à jour: Joyent a maintenant son propre guide . Les informations suivantes sont plutôt un résumé:

Erreurs de «lancement» en toute sécurité

Idéalement, nous aimerions éviter les erreurs non capturées autant que possible, en tant que tel, au lieu de jeter littéralement l'erreur, nous pouvons à la place "jeter" l'erreur en utilisant l'une des méthodes suivantes en fonction de notre architecture de code:

• Pour le code synchrone, si une erreur se produit, renvoyez l'erreur:

  // Define divider as a syncrhonous function
  var divideSync = function(x,y) {
      // if error condition?
      if ( y === 0 ) {
          // "throw" the error safely by returning it
          return new Error("Can't divide by zero")
      }
      else {
          // no error occured, continue on
          return x/y
      }
  }
  
  // Divide 4/2
  var result = divideSync(4,2)
  // did an error occur?
  if ( result instanceof Error ) {
      // handle the error safely
      console.log('4/2=err', result)
  }
  else {
      // no error occured, continue on
      console.log('4/2='+result)
  }
  
  // Divide 4/0
  result = divideSync(4,0)
  // did an error occur?
  if ( result instanceof Error ) {
      // handle the error safely
      console.log('4/0=err', result)
  }
  else {
      // no error occured, continue on
      console.log('4/0='+result)
  }

• Pour le code basé sur le rappel (c'est-à-dire asynchrone), le premier argument du rappel est err, si une erreur se produit errest l'erreur, si une erreur ne se produit pas, elle l' errest null. Tout autre argument suit l' errargument:

  var divide = function(x,y,next) {
      // if error condition?
      if ( y === 0 ) {
          // "throw" the error safely by calling the completion callback
          // with the first argument being the error
          next(new Error("Can't divide by zero"))
      }
      else {
          // no error occured, continue on
          next(null, x/y)
      }
  }
  
  divide(4,2,function(err,result){
      // did an error occur?
      if ( err ) {
          // handle the error safely
          console.log('4/2=err', err)
      }
      else {
          // no error occured, continue on
          console.log('4/2='+result)
      }
  })
  
  divide(4,0,function(err,result){
      // did an error occur?
      if ( err ) {
          // handle the error safely
          console.log('4/0=err', err)
      }
      else {
          // no error occured, continue on
          console.log('4/0='+result)
      }
  })

• Pour le code mouvementé , où l'erreur peut se produire n'importe où, au lieu de lancer l'erreur, déclenchez l' errorévénement à la place :

  // Definite our Divider Event Emitter
  var events = require('events')
  var Divider = function(){
      events.EventEmitter.call(this)
  }
  require('util').inherits(Divider, events.EventEmitter)
  
  // Add the divide function
  Divider.prototype.divide = function(x,y){
      // if error condition?
      if ( y === 0 ) {
          // "throw" the error safely by emitting it
          var err = new Error("Can't divide by zero")
          this.emit('error', err)
      }
      else {
          // no error occured, continue on
          this.emit('divided', x, y, x/y)
      }
  
      // Chain
      return this;
  }
  
  // Create our divider and listen for errors
  var divider = new Divider()
  divider.on('error', function(err){
      // handle the error safely
      console.log(err)
  })
  divider.on('divided', function(x,y,result){
      console.log(x+'/'+y+'='+result)
  })
  
  // Divide
  divider.divide(4,2).divide(4,0)

"Attraper" les erreurs en toute sécurité

Parfois, cependant, il peut toujours y avoir du code qui génère une erreur quelque part, ce qui peut entraîner une exception non interceptée et un crash potentiel de notre application si nous ne l'attrapons pas en toute sécurité. Selon notre architecture de code, nous pouvons utiliser l'une des méthodes suivantes pour l'attraper:

• Lorsque nous savons où l'erreur se produit, nous pouvons envelopper cette section dans un domaine node.js

  var d = require('domain').create()
  d.on('error', function(err){
      // handle the error safely
      console.log(err)
  })
  
  // catch the uncaught errors in this asynchronous or synchronous code block
  d.run(function(){
      // the asynchronous or synchronous code that we want to catch thrown errors on
      var err = new Error('example')
      throw err
  })

• Si nous savons où l'erreur se produit, c'est du code synchrone, et pour une raison quelconque, nous ne pouvons pas utiliser de domaines (peut-être l'ancienne version du nœud), nous pouvons utiliser l'instruction try catch:

  // catch the uncaught errors in this synchronous code block
  // try catch statements only work on synchronous code
  try {
      // the synchronous code that we want to catch thrown errors on
      var err = new Error('example')
      throw err
  } catch (err) {
      // handle the error safely
      console.log(err)
  }

  Cependant, veillez à ne pas utiliser try...catchdans le code asynchrone, car une erreur levée de manière asynchrone ne sera pas détectée:

  try {
      setTimeout(function(){
          var err = new Error('example')
          throw err
      }, 1000)
  }
  catch (err) {
      // Example error won't be caught here... crashing our app
      // hence the need for domains
  }

  Si vous souhaitez travailler avec try..catchen conjonction avec du code asynchrone, lorsque vous exécutez Node 7.4 ou supérieur, vous pouvez utiliserasync/await nativement pour écrire vos fonctions asynchrones.

  Une autre chose à laquelle vous devez faire attention try...catchest le risque d'encapsuler votre rappel de fin dans l' tryinstruction comme ceci:

  var divide = function(x,y,next) {
      // if error condition?
      if ( y === 0 ) {
          // "throw" the error safely by calling the completion callback
          // with the first argument being the error
          next(new Error("Can't divide by zero"))
      }
      else {
          // no error occured, continue on
          next(null, x/y)
      }
  }
  
  var continueElsewhere = function(err, result){
          throw new Error('elsewhere has failed')
  }
  
  try {
          divide(4, 2, continueElsewhere)
          // ^ the execution of divide, and the execution of 
          //   continueElsewhere will be inside the try statement
  }
  catch (err) {
          console.log(err.stack)
          // ^ will output the "unexpected" result of: elsewhere has failed
  }

  Ce gotcha est très facile à faire car votre code devient plus complexe. En tant que tel, il est préférable d'utiliser des domaines ou de renvoyer des erreurs pour éviter (1) les exceptions non interceptées dans le code asynchrone (2) l'exécution de capture catch try que vous ne voulez pas. Dans les langages qui permettent un threading approprié au lieu du style de machine d'événement asynchrone de JavaScript, cela pose moins de problème.

• Enfin, dans le cas où une erreur non interceptée se produit dans un endroit qui n'était pas encapsulé dans un domaine ou une instruction try catch, nous pouvons empêcher notre application de se bloquer en utilisant l' uncaughtExceptionécouteur (cependant, cela peut mettre l'application dans un état inconnu ):

  // catch the uncaught errors that weren't wrapped in a domain or try catch statement
  // do not use this in modules, but only in applications, as otherwise we could have multiple of these bound
  process.on('uncaughtException', function(err) {
      // handle the error safely
      console.log(err)
  })
  
  // the asynchronous or synchronous code that emits the otherwise uncaught error
  var err = new Error('example')
  throw err

Vous trouverez ci-dessous un résumé et une sélection de nombreuses sources différentes sur ce sujet, y compris un exemple de code et des citations de certains articles de blog. La liste complète des meilleures pratiques se trouve ici

Meilleures pratiques de gestion des erreurs Node.JS

Number1: Utilisez des promesses pour la gestion des erreurs asynchrones

TL; DR: gestion des erreurs asynchrones dans le style de rappel est probablement le moyen le plus rapide d'enfer (alias la pyramide du destin). Le meilleur cadeau que vous puissiez faire à votre code est d'utiliser à la place une bibliothèque de promesses réputée qui fournit une syntaxe de code bien compacte et familière comme try-catch

Autrement: style de rappel Node.JS, la fonction (erreur, réponse), est un moyen prometteur de code non maintenable en raison de la combinaison de la gestion des erreurs avec du code occasionnel, de l'imbrication excessive et des modèles de codage maladroits

Exemple de code - bon

doWork()
.then(doWork)
.then(doError)
.then(doWork)
.catch(errorHandler)
.then(verify);

exemple de code anti modèle - gestion des erreurs de style de rappel

getData(someParameter, function(err, result){
    if(err != null)
      //do something like calling the given callback function and pass the error
    getMoreData(a, function(err, result){
          if(err != null)
            //do something like calling the given callback function and pass the error
        getMoreData(b, function(c){ 
                getMoreData(d, function(e){ 
                    ...
                });
            });
        });
    });
});

Citation du blog: "Nous avons un problème avec les promesses" (extrait du blog pouchdb, classé 11 pour les mots clés "Node Promises")

"… Et en fait, les rappels font quelque chose de plus sinistre encore: ils nous privent de la pile, ce que nous tenons généralement pour acquis dans les langages de programmation. Écrire du code sans pile, c'est un peu comme conduire une voiture sans pédale de frein: vous ne réalisez pas à quel point vous en avez besoin, tant que vous ne l'avez pas atteint et qu'il n'est pas là. Le but des promesses est de nous rendre les bases linguistiques que nous avons perdues lorsque nous sommes allés en mode asynchrone: le retour, le lancer et la pile. Mais vous doivent savoir utiliser correctement les promesses afin d'en tirer parti. "

Number2: utilisez uniquement l'objet Error intégré

TL; DR: Il est assez courant de voir du code qui génère des erreurs sous forme de chaîne ou de type personnalisé - cela complique la logique de gestion des erreurs et l'interopérabilité entre les modules. Que vous rejetiez une promesse, leviez une exception ou émettiez une erreur, l'utilisation de l'objet d'erreur intégré Node.JS augmente l'uniformité et empêche la perte d'informations sur les erreurs

Sinon: lors de l'exécution d'un module, le fait de savoir quel type d'erreurs en retour est incertain - rend beaucoup plus difficile de raisonner sur l'exception à venir et de la gérer. Même utile, l'utilisation de types personnalisés pour décrire des erreurs peut entraîner la perte d'informations sur les erreurs critiques comme la trace de la pile!

Exemple de code - bien faire

    //throwing an Error from typical function, whether sync or async
 if(!productToAdd)
 throw new Error("How can I add new product when no value provided?");

//'throwing' an Error from EventEmitter
const myEmitter = new MyEmitter();
myEmitter.emit('error', new Error('whoops!'));

//'throwing' an Error from a Promise
 return new promise(function (resolve, reject) {
 DAL.getProduct(productToAdd.id).then((existingProduct) =>{
 if(existingProduct != null)
 return reject(new Error("Why fooling us and trying to add an existing product?"));

exemple de code anti motif

//throwing a String lacks any stack trace information and other important properties
if(!productToAdd)
    throw ("How can I add new product when no value provided?");

Citation du blog: "Une chaîne n'est pas une erreur" (D'après le blog devthought, classé 6 pour les mots clés "Node.JS error object")

"… La transmission d'une chaîne au lieu d'une erreur entraîne une interopérabilité réduite entre les modules. Elle rompt les contrats avec les API qui pourraient effectuer des vérifications d'erreurs ou qui souhaitent en savoir plus sur l'erreur . Les objets d'erreur, comme nous le verrons, ont très propriétés intéressantes dans les moteurs JavaScript modernes en plus de contenir le message transmis au constructeur .. "

Numéro3: Distinguer les erreurs opérationnelles des erreurs de programmation

TL; DR: les erreurs d'opération (par exemple, l'API a reçu une entrée non valide) se réfèrent à des cas connus où l'impact de l'erreur est entièrement compris et peut être géré de manière réfléchie. D'autre part, une erreur de programmeur (par exemple, essayer de lire une variable non définie) fait référence à des échecs de code inconnus qui dictent de redémarrer l'application avec grâce.

Sinon: vous pouvez toujours redémarrer l'application lorsqu'une erreur apparaît, mais pourquoi laisser ~ 5000 utilisateurs en ligne en raison d'une erreur mineure et prédite (erreur opérationnelle)? l'inverse n'est pas non plus idéal - garder l'application en place lorsqu'un problème inconnu (erreur de programmation) s'est produit peut entraîner un comportement imprévu. Différencier les deux permet d'agir avec tact et d'appliquer une approche équilibrée en fonction du contexte donné

Exemple de code - bien faire

    //throwing an Error from typical function, whether sync or async
 if(!productToAdd)
 throw new Error("How can I add new product when no value provided?");

//'throwing' an Error from EventEmitter
const myEmitter = new MyEmitter();
myEmitter.emit('error', new Error('whoops!'));

//'throwing' an Error from a Promise
 return new promise(function (resolve, reject) {
 DAL.getProduct(productToAdd.id).then((existingProduct) =>{
 if(existingProduct != null)
 return reject(new Error("Why fooling us and trying to add an existing product?"));

exemple de code - marquer une erreur comme opérationnelle (fiable)

//marking an error object as operational 
var myError = new Error("How can I add new product when no value provided?");
myError.isOperational = true;

//or if you're using some centralized error factory (see other examples at the bullet "Use only the built-in Error object")
function appError(commonType, description, isOperational) {
    Error.call(this);
    Error.captureStackTrace(this);
    this.commonType = commonType;
    this.description = description;
    this.isOperational = isOperational;
};

throw new appError(errorManagement.commonErrors.InvalidInput, "Describe here what happened", true);

//error handling code within middleware
process.on('uncaughtException', function(error) {
    if(!error.isOperational)
        process.exit(1);
});

Citation de blog : "Sinon, vous risquez l'état" (D'après le blog débogable, classé 3 pour les mots clés "Node.JS uncaught exception")

" ... De par la nature même du fonctionnement de throw en JavaScript, il n'y a presque jamais moyen de" reprendre là où vous vous étiez arrêté "en toute sécurité, sans divulguer de références, ou créer une autre sorte d'état fragile indéfini. La manière la plus sûre de répondre à une erreur renvoyée consiste à arrêter le processus . Bien sûr, dans un serveur Web normal, de nombreuses connexions peuvent être ouvertes, et il n'est pas raisonnable de les fermer brutalement car une erreur a été déclenchée par quelqu'un d'autre. La meilleure approche consiste à envoyer une réponse d'erreur à la demande qui a déclenché l'erreur, tout en laissant les autres terminer dans leur temps normal, et arrêter d'écouter les nouvelles demandes de ce travailleur "

Number4: Gérer les erreurs de manière centralisée, mais pas dans le middleware

TL; DR: la logique de gestion des erreurs, comme le courrier à l'administrateur et la journalisation, doit être encapsulée dans un objet dédié et centralisé que tous les points finaux (par exemple, middleware Express, tâches cron, tests unitaires) appellent lorsqu'une erreur survient.

Sinon: le fait de ne pas traiter les erreurs au sein d'un même emplacement entraînera une duplication de code et probablement des erreurs mal gérées.

Exemple de code - un flux d'erreur typique

//DAL layer, we don't handle errors here
DB.addDocument(newCustomer, (error, result) => {
    if (error)
        throw new Error("Great error explanation comes here", other useful parameters)
});

//API route code, we catch both sync and async errors and forward to the middleware
try {
    customerService.addNew(req.body).then(function (result) {
        res.status(200).json(result);
    }).catch((error) => {
        next(error)
    });
}
catch (error) {
    next(error);
}

//Error handling middleware, we delegate the handling to the centrzlied error handler
app.use(function (err, req, res, next) {
    errorHandler.handleError(err).then((isOperationalError) => {
        if (!isOperationalError)
            next(err);
    });
});

Citation du blog: "Parfois, les niveaux inférieurs ne peuvent rien faire d'utile sauf propager l'erreur à leur appelant" (D'après le blog Joyent, classé 1 pour les mots clés "Gestion des erreurs Node.JS")

"... Vous pouvez finir par gérer la même erreur à plusieurs niveaux de la pile. Cela se produit lorsque les niveaux inférieurs ne peuvent rien faire d'utile, sauf propager l'erreur à leur appelant, qui la propage à son appelant, et ainsi de suite. Souvent, seul l'appelant de niveau supérieur sait quelle est la réponse appropriée, que ce soit pour recommencer l'opération, signaler une erreur à l'utilisateur ou autre chose. Mais cela ne signifie pas que vous devez essayer de signaler toutes les erreurs à un seul niveau supérieur rappel, car ce rappel lui-même ne peut pas savoir dans quel contexte l'erreur s'est produite "

Number5: documenter les erreurs de l'API à l'aide de Swagger

TL; DR: laissez vos appelants API savoir quelles erreurs peuvent survenir en retour afin de pouvoir les traiter de manière réfléchie sans se bloquer. Cela se fait généralement avec les cadres de documentation de l'API REST comme Swagger

Sinon: un client API peut décider de planter et de redémarrer uniquement parce qu'il a reçu une erreur qu'il ne pouvait pas comprendre. Remarque: l'appelant de votre API peut être vous (très typique dans un environnement de microservices)

Citation du blog: "Vous devez dire à vos appelants quelles erreurs peuvent se produire" (tiré du blog Joyent, classé 1 pour les mots clés "Journalisation Node.JS")

… Nous avons parlé de la façon de gérer les erreurs, mais lorsque vous écrivez une nouvelle fonction, comment envoyez-vous des erreurs au code qui a appelé votre fonction? … Si vous ne savez pas quelles erreurs peuvent se produire ou si vous ne savez pas ce qu'elles signifient, votre programme ne peut être correct, sauf par accident. Donc, si vous écrivez une nouvelle fonction, vous devez dire à vos appelants quelles erreurs peuvent se produire et ce qu'elles

Number6: Arrêtez le processus gracieusement quand un étranger vient en ville

TL; DR: Lorsqu'une erreur inconnue se produit (une erreur de développeur, voir la meilleure pratique numéro 3) - il y a une incertitude sur la salubrité de l'application. Une pratique courante suggère de redémarrer le processus avec précaution à l'aide d'un outil de «redémarrage» comme Forever et PM2

Sinon: lorsqu'une exception inconnue est interceptée, un objet peut être dans un état défectueux (par exemple, un émetteur d'événements qui est utilisé globalement et ne déclenche plus d'événements en raison d'une défaillance interne) et toutes les demandes futures peuvent échouer ou se comporter de manière folle

Exemple de code - décider s'il faut planter

//deciding whether to crash when an uncaught exception arrives
//Assuming developers mark known operational errors with error.isOperational=true, read best practice #3
process.on('uncaughtException', function(error) {
 errorManagement.handler.handleError(error);
 if(!errorManagement.handler.isTrustedError(error))
 process.exit(1)
});


//centralized error handler encapsulates error-handling related logic 
function errorHandler(){
 this.handleError = function (error) {
 return logger.logError(err).then(sendMailToAdminIfCritical).then(saveInOpsQueueIfCritical).then(determineIfOperationalError);
 }

 this.isTrustedError = function(error)
 {
 return error.isOperational;
 }

Citation du blog: "Il existe trois écoles de pensée sur la gestion des erreurs" (tiré du blog jsrecipes)

… Il existe principalement trois écoles de pensée sur la gestion des erreurs: 1. Laissez l'application se bloquer et redémarrez-la. 2. Gérez toutes les erreurs possibles et ne plantez jamais. 3. Approche équilibrée entre les deux

Number7: Utilisez un enregistreur mature pour augmenter la visibilité des erreurs

TL; DR: un ensemble d'outils de journalisation matures comme Winston, Bunyan ou Log4J, accélérera la découverte et la compréhension des erreurs. Oubliez donc console.log.

Sinon: le survol via console.logs ou manuellement via un fichier texte en désordre sans outils d'interrogation ou une visionneuse de journal décente peut vous occuper au travail jusqu'à tard

Exemple de code - Enregistreur Winston en action

//your centralized logger object
var logger = new winston.Logger({
 level: 'info',
 transports: [
 new (winston.transports.Console)(),
 new (winston.transports.File)({ filename: 'somefile.log' })
 ]
 });

//custom code somewhere using the logger
logger.log('info', 'Test Log Message with some parameter %s', 'some parameter', { anything: 'This is metadata' });

Citation du blog: "Permet d'identifier quelques exigences (pour un enregistreur):" (Sur le blog strongblog)

… Permet d'identifier quelques exigences (pour un enregistreur): 1. Horodatage de chaque ligne de journal. Celui-ci est assez explicite - vous devriez pouvoir dire quand chaque entrée de journal s'est produite. 2. Le format d'enregistrement devrait être facilement assimilable par les humains ainsi que par les machines. 3. Permet plusieurs flux de destination configurables. Par exemple, vous pouvez écrire des journaux de trace dans un fichier, mais lorsqu'une erreur se produit, écrivez dans le même fichier, puis dans le fichier d'erreur et envoyez un e-mail en même temps…

Number8: Découvrez les erreurs et les temps d'arrêt en utilisant les produits APM

TL; DR: les produits de surveillance et de performance (aka APM) évaluent de manière proactive votre base de code ou votre API afin qu'ils puissent mettre en évidence automatiquement les erreurs, les plantages et les ralentissements qui vous manquaient

Sinon: vous pourriez consacrer beaucoup d'efforts à mesurer les performances et les temps d'arrêt de l'API, vous ne saurez probablement jamais quelles sont vos parties de code les plus lentes dans le scénario du monde réel et comment elles affectent l'UX

Citation du blog: "Segments de produits APM" (Extrait du blog Yoni Goldberg)

"… Les produits APM constituent 3 segments principaux: 1. Surveillance de sites Web ou d'API - services externes qui surveillent constamment la disponibilité et les performances via des requêtes HTTP. Peut être configuré en quelques minutes. Voici quelques candidats sélectionnés: Pingdom, Uptime Robot et New Relic 2 Instrumentation de code - famille de produits qui nécessitent d'incorporer un agent dans l'application pour bénéficier de la détection de code lent, des statistiques d'exceptions, de la surveillance des performances et bien d'autres encore. Voici quelques candidats sélectionnés: New Relic, App Dynamics 3. Tableau de bord de l'intelligence opérationnelle -ces gammes de produits sont axées sur la facilitation de l'équipe des opérations avec des métriques et du contenu organisé qui permettent de rester facilement au top des performances des applications. Cela implique généralement d'agréger plusieurs sources d'informations (journaux d'application, journaux de base de données, journal de serveurs, etc.) et de concevoir un tableau de bord initial. Voici quelques candidats sélectionnés: Datadog, Splunk "

Ce qui précède est une version abrégée - voir ici plus de bonnes pratiques et d'exemples

Vous pouvez intercepter des exceptions non capturées, mais son utilisation est limitée. Voir http://debuggable.com/posts/node-js-dealing-with-uncaught-exceptions:4c933d54-1428-443c-928d-4e1ecbdd56cb

monit, foreverou upstartpeut être utilisé pour redémarrer le processus de nœud lorsqu'il se bloque. Vous pouvez espérer un arrêt gracieux (par exemple, enregistrer toutes les données en mémoire dans un gestionnaire d'exceptions non capturé).

Les domaines nodejs sont le moyen le plus à jour de gérer les erreurs dans nodejs. Les domaines peuvent capturer à la fois des événements d'erreur / autres ainsi que des objets traditionnellement levés. Les domaines fournissent également des fonctionnalités pour gérer les rappels avec une erreur transmise comme premier argument via la méthode d'interception.

Comme avec la gestion normale des erreurs de style try / catch, il est généralement préférable de lever les erreurs lorsqu'elles se produisent et de bloquer les zones où vous souhaitez isoler les erreurs d'affecter le reste du code. Le moyen de "bloquer" ces zones consiste à appeler domain.run avec une fonction de bloc de code isolé.

En code synchrone, ce qui précède est suffisant - lorsqu'une erreur se produit, vous pouvez soit la laisser passer, soit l'attraper et la gérer, en rétablissant toutes les données dont vous avez besoin.

try {  
  //something
} catch(e) {
  // handle data reversion
  // probably log too
}

Lorsque l'erreur se produit dans un rappel asynchrone, vous devez soit être en mesure de gérer entièrement la restauration des données (état partagé, données externes comme les bases de données, etc.). OU vous devez définir quelque chose pour indiquer qu'une exception s'est produite - chaque fois que vous vous souciez de cet indicateur, vous devez attendre la fin du rappel.

var err = null;
var d = require('domain').create();
d.on('error', function(e) {
  err = e;
  // any additional error handling
}
d.run(function() { Fiber(function() {
  // do stuff
  var future = somethingAsynchronous();
  // more stuff

  future.wait(); // here we care about the error
  if(err != null) {
    // handle data reversion
    // probably log too
  }

})});

Une partie de ce code ci-dessus est moche, mais vous pouvez créer des modèles pour le rendre plus joli, par exemple:

var specialDomain = specialDomain(function() {
  // do stuff
  var future = somethingAsynchronous();
  // more stuff

  future.wait(); // here we care about the error
  if(specialDomain.error()) {
    // handle data reversion
    // probably log too
  } 
}, function() { // "catch"
  // any additional error handling
});

MISE À JOUR (2013-09):

Ci-dessus, j'utilise un futur qui implique la sémantique des fibres , qui vous permet d'attendre les futures en ligne. Cela vous permet en fait d'utiliser des blocs try-catch traditionnels pour tout - ce que je trouve être la meilleure façon de procéder. Cependant, vous ne pouvez pas toujours le faire (c'est-à-dire dans le navigateur) ...

Il existe également des futurs qui ne nécessitent pas de sémantique de fibres (qui fonctionnent ensuite avec du JavaScript normal pour navigateur). Ceux-ci peuvent être appelés contrats à terme, promesses ou différés (je ferai référence aux contrats à terme à partir d'ici). Les bibliothèques de futures JavaScript simples permettent de propager les erreurs entre les futures. Seules certaines de ces bibliothèques permettent de gérer correctement tout avenir jeté, alors méfiez-vous.

Un exemple:

returnsAFuture().then(function() {
  console.log('1')
  return doSomething() // also returns a future

}).then(function() {
  console.log('2')
  throw Error("oops an error was thrown")

}).then(function() {
  console.log('3')

}).catch(function(exception) {
  console.log('handler')
  // handle the exception
}).done()

Cela imite un try-catch normal, même si les pièces sont asynchrones. Il imprimerait:

1
2
handler

Notez qu'il n'imprime pas «3» car une exception a été levée qui interrompt ce flux.

Jetez un œil aux promesses de Bluebird:

• https://github.com/petkaantonov/bluebird

Notez que je n'ai pas trouvé beaucoup d'autres bibliothèques autres que celles-ci qui gèrent correctement les exceptions levées. Le différé de jQuery, par exemple, ne le fait pas - le gestionnaire «fail» ne verrait jamais l'exception levée par un gestionnaire «then», qui à mon avis est un facteur de rupture.

J'ai récemment écrit à ce sujet sur http://snmaynard.com/2012/12/21/node-error-handling/ . Une nouvelle fonctionnalité du nœud dans la version 0.8 est les domaines et vous permet de combiner toutes les formes de gestion des erreurs en un seul formulaire de gestion plus facile. Vous pouvez en lire plus dans mon article.

Vous pouvez également utiliser quelque chose comme Bugsnag pour suivre vos exceptions non capturées et être averti par e-mail, sur le chat ou faire créer un ticket pour une exception non capturée (je suis le co-fondateur de Bugsnag).

Je voudrais juste ajouter que la bibliothèque Step.js vous aide à gérer les exceptions en la passant toujours à la fonction de l'étape suivante. Par conséquent, vous pouvez avoir comme dernière étape une fonction qui vérifie les erreurs dans l'une des étapes précédentes. Cette approche peut simplifier considérablement la gestion des erreurs.

Voici une citation de la page github:

toutes les exceptions levées sont interceptées et passées comme premier argument à la fonction suivante. Tant que vous n'imbriquez pas de fonctions de rappel dans vos fonctions principales, cela empêche qu'il n'y ait jamais d'exceptions non capturées. Ceci est très important pour les serveurs node.JS de longue durée, car une seule exception non interceptée peut entraîner l'arrêt complet du serveur.

De plus, vous pouvez utiliser Step pour contrôler l'exécution des scripts afin d'avoir une section de nettoyage comme dernière étape. Par exemple, si vous souhaitez écrire un script de génération dans Node et indiquer le temps qu'il a fallu pour écrire, la dernière étape peut le faire (plutôt que d'essayer de déterrer le dernier rappel).

Une instance où l'utilisation d'un try-catch peut être appropriée est lors de l'utilisation d'une boucle forEach. Il est synchrone mais en même temps, vous ne pouvez pas simplement utiliser une instruction de retour dans la portée interne. Au lieu de cela, une approche try and catch peut être utilisée pour renvoyer un objet Error dans la portée appropriée. Considérer:

function processArray() {
    try { 
       [1, 2, 3].forEach(function() { throw new Error('exception'); }); 
    } catch (e) { 
       return e; 
    }
}

Il s'agit d'une combinaison des approches décrites par @balupton ci-dessus.

Après avoir lu ce post il y a quelque temps, je me demandais s'il était sûr d'utiliser des domaines pour la gestion des exceptions au niveau de l'api / fonction. Je voulais les utiliser pour simplifier le code de gestion des exceptions dans chaque fonction asynchrone que j'ai écrite. Ma préoccupation était que l'utilisation d'un nouveau domaine pour chaque fonction entraînerait une surcharge importante. Mes devoirs semblent indiquer que les frais généraux sont minimes et que les performances sont en fait meilleures avec les domaines qu'avec try catch dans certaines situations.

http://www.lighthouselogic.com/#/using-a-new-domain-for-each-async-function-in-node/

La détection des erreurs a été très bien discutée ici, mais il convient de se rappeler de déconnecter les erreurs quelque part afin de pouvoir les afficher et corriger les problèmes.

Bunyan est un cadre de journalisation populaire pour NodeJS - il supprime l'écriture dans un tas d'endroits de sortie différents, ce qui le rend utile pour le débogage local, tant que vous évitez console.log. Dans le gestionnaire d'erreurs de votre domaine, vous pouvez cracher l'erreur dans un fichier journal.

var log = bunyan.createLogger({
  name: 'myapp',
  streams: [
    {
      level: 'error',
      path: '/var/tmp/myapp-error.log'  // log ERROR to this file
    }
  ]
});

Cela peut prendre du temps si vous avez beaucoup d'erreurs et / ou de serveurs à vérifier, il pourrait donc être utile d'examiner un outil comme Raygun (clause de non-responsabilité, je travaille chez Raygun) pour regrouper les erreurs - ou les utiliser les deux ensemble. Si vous avez décidé d'utiliser Raygun comme outil, il est également assez facile à configurer

var raygunClient = new raygun.Client().init({ apiKey: 'your API key' });
raygunClient.send(theError);

Croisée avec l'utilisation d'un outil comme PM2 ou pour toujours, votre application devrait pouvoir planter, déconnecter ce qui s'est passé et redémarrer sans aucun problème majeur.

Si vous souhaitez utiliser les services dans Ubuntu (Upstart): Node as a service in Ubuntu 11.04 with upstart, monit and forever.js