2011-04-07 3 views
1

J'ai regardé à travers les discussions ici sur ce sujet et je ne trouve pas ce que je veux.Comment est-ce que je peux emballer ces fonctions afin que leurs exceptions soient toujours traitées?

J'ai un tas de fonctions qui retournent la chaîne et je veux qu'ils ne retournent pas une chaîne si l'entrée est mauvaise et je ne veux pas que le programme quitte non plus ET je ne veux pas emballer tous les appels/capture.

function foo(num){ 
    if(num > 5){ 
    throw SomeException("Input too big") 
    }else{ 
    return "bar"+num 
    } 
} 

Je veux enregistrer une erreur comme « 6 est trop grand pour foo », au lieu de quitter le programme. Mais ce sera une sorte d'API, donc je ne veux pas que l'utilisateur doive essayer/attraper chaque fois qu'il utilise une de ces fonctions. Ceci est un script nodejs.

cela fonctionne, mais est maladroit:

f = { 
    command : function(cmd,arg){ 
       try { 
       console.log(q[cmd](arg)); 
       } 
       catch (e) { 
       console.log("Error: " + e + " for " + cmd); 
       } 
      }, 
    foo : function(str){ 
       throw ("foo error"); 
     }, 
    foo2 : function(str){ 
      throw ("foo2 error"); 
     } 

}; 
f.command("foo",2); 
f.command("foo2",3); 

Répondre

1

[[Éditer]] C'est un script nodeJS. Ensuite, rendez l'API asynchrone. Nous ne faisons pas d'opérations synchrones dans nodeJS. Veuillez conserver la boucle d'événement.

Vous pouvez également retravailler votre API pour être asynchrone

function foo(num, cb){ 
    if(num > 5){ 
    cb(SomeException("Input too big")); 
    }else{ 
    cb(null, "bar"+num); 
    } 
} 

foo(5, function(err, data) { 
    ... 
}); 

Vous pouvez faire référence à une instance de l'enregistreur public.

MyLibrary.errorHandler = defaultErrorHandler() || config.errorHandler

Puis ont le DefaultErrorHandler être

function(error) { 
    if (console && console.log) { console.log(error.message); } 
    $("#errordiv").text(error.message); 
} 

function foo(num){ 
    if(num > 5){ 
    MyLibrary.errorHandler(new Exception("blargh")); 
    }else{ 
    return "bar"+num; 
    } 
} 
+0

Je dois m'assurer que je suis asynchrone sur ces petites fonctions? – tladuke

+0

@tladuke J'ai supposé que votre exemple était trop trivial. Si vous voulez bien gérer les erreurs, alors ce modèle asynchrone est sympa. tout le modèle 'next' est aussi sympa. – Raynos

1

Si vous créez une API que les autres utiliseront, et que vous souhaitez signaler qu'une erreur est survenue, bien ... jeter une exception. Si cette exception n'est pas interceptée par le programmeur utilisant votre API, c'est leur faute, pas la vôtre; d'un autre côté, si leur code est tout bête parce que votre fonction fait quelque chose de vraiment bizarre sur une erreur, eh bien, c'est toujours la faute de l'autre programmeur de ne pas vérifier correctement les entrées arrivant dans votre API, mais soyez un bon citoyen aider leur débogage en lançant cette exception. Ils peuvent ne pas vous aimer pour mettre des exceptions partout, mais ils vont vous haïr si votre code fait silencieusement des choses vraiment étranges au lieu de fournir une bonne indication de ce qu'est l'erreur.

Je dirais que vous consignez l'erreur aussi, mais vous le faites en JavaScript, où il n'y a pas de telles possibilités. Pour l'anecdote, cela vient d'un programmeur qui a utilisé des API qui à la fois font et ne lancent pas d'exceptions sur les erreurs; ceux qui les lancent sont généralement ceux que je considère comme mieux écrits.

+0

Je vois ce que vous dites. Ceci est pour formater les chaînes pour aller à un morceau de matériel. Si les chaînes ne sont pas formatées correctement (hors de portée), tout ce qui arrive est que l'appareil ne répond pas. Pas la peine de planter le programme, mais je pensais que ce serait bien de leur faire savoir pourquoi rien ne s'est passé quand ils ont envoyé une commande malformée. – tladuke

+0

Les exceptions leur permettent de savoir pourquoi leur code a échoué de la plus forte voix possible! ;-) Il leur permet également de configurer leur propre code pour gérer les erreurs - peut-être qu'ils veulent tuer le programme, peut-être qu'ils veulent le connecter puis passer à autre chose, ou peut-être qu'ils ont un moyen de résoudre le problème par programme travail. Point étant, pourquoi les classer dans une façon d'aborder une condition d'erreur quand vous pouvez plutôt leur donner les outils pour le faire eux-mêmes? – Kromey

+0

essayer et attraper peut vraiment ralentir un programme. C'est bien pour le débogage mais dans le code de production ce n'est pas vraiment voulu. Vous voulez gérer les mauvaises entrées d'une manière différente si possible. – Raynos

Questions connexes