Pourquoi les bons programmeurs avalent-ils parfois silencieusement des exceptions?

Question

Je sais que c'est mal, mais j'ai vu des exceptions avalées dans du code écrit par un bon programmeur. Je me demande donc si cette mauvaise pratique pourrait avoir au moins un point positif.

En d'autres termes, c'est mauvais, mais pourquoi les bons programmeurs l'utilisent-ils en de rares occasions?

 try
{
    //Some code
}
catch(Exception){}
 

Answer 1

En regardant dans mon propre code, j'ai trouvé un endroit dans mon code de journalisation où, après avoir échoué dans un fichier et dans le journal des événements, il avale l'erreur car il n'y a plus de place pour le signaler. Voilà un exemple: il n'y en a pas beaucoup d'autres.

Answer 2

Parce que parfois, le programmeur a plus de connaissance que le compilateur.

E. g. (dans certains de fiction de langue où la division par zéro est considéré comme une erreur):

try {
    x = 1 / (a*a + 1);
} catch (DivisionByZeroException ex) {
  // Cannot happen as a*a+1 is always positive
}

Comme certaines langues (par exemple Java) nécessitent pour prendre un peu de/beaucoup de/toutes les exceptions, le compilateur peut se plaindre alors que le programmeur sait qu'il n'est pas possible. Parfois, la seule façon d'obtenir le compilateur de la fermer, est explicitement avaler l'exception.

Dans les langues où le compilateur ne se plaint pas, le vide de capture n'est généralement pas écrit du tout.

Edit: Dans la pratique, je voudrais ajouter un assert(false) dans le bloc catch. Si, théoriquement, quelque chose ne peut pas arriver, c'est un problème très sérieux quand il arrive dans la pratique ;)

Edit2: Java ne demande qu'à attraper checked exceptions. Reformulé ma déclaration un peu.

Answer 3

Je dirais qu'un bon programmeur ne le ferais pas, sans l'expliquer.

try
{
    //Some code
}
catch(Exception e) {
    // Explanation of why the exception is being swallowed.
}

Je suis très peu probable juste silencieusement avaler la base Exception classe si, pour une raison quelconque. J'aurais au moins essayer de le journal de l'erreur.

---

Voici un exemple concret que j'ai juste arrivé de courir à travers aujourd'hui dans mon projet. Cette est une partie d'une fonction JavaScript qui obtient une XMLHttpRequest pris en charge par le navigateur.

var XMLHttp = null;

if( window.XMLHttpRequest ) {
    try {
        XMLHttp = new XMLHttpRequest();
    } catch(e) {} // we've already checked that this is safe. 
}
else if( window.ActiveXObject ) {
...
}

Depuis l' try est enveloppé dans un if...else if qui vérifie le type d'objet à créer, il est sûr que d'avaler de l'exception.

Answer 4

Parce que parfois de bons programmeurs font des erreurs.

Soit cela, soit votre opinion sur un bon programmeur n'est pas la même chose que certains (car un bon programmeur aurait laissé un raisonnement sur la raison pour laquelle l'exception a été avalée plutôt que quelque chose à faire avec les informations).

Answer 5

Oui, je les utilise assez souvent dans exception de nettoyage de code, de sorte que je n'ai pas de masque à l'exception d'origine.

Par exemple, si votre gestionnaire catch est d'essayer de la restauration d'une transaction et de fermer une connexion avant de rethowing l'exception, il pourrait y avoir plusieurs raisons pour que la restauration/fermer lui-même pourrait échouer (puisque vous êtes déjà dans certains jusqu'à éclaté comme un résultat de l'exception d'origine). Donc, pouvez encapsuler le nettoyer dans un bloc try avec un vide gestionnaire catch, ce qui revient à dire "si quelque chose va mal dans le nettoyage, c'est en quelque sorte-de-OK, depuis que nous avons de plus gros problèmes à signaler"