Dois-je attraper les exceptions levées lors de la fermeture de java.sql.Connection

Connection.close() peut jeter SqlExceptionmais j'ai toujours pensé qu'il est sûr d'ignorer de telles exceptions (et je n'ai jamais vu de code qui ne permet pas de les ignorer).

Normalement, je devrais écrire:

 try{
    connection.close();
 }catch(Exception e) {}

Ou 

 try{
    connection.close();
 }catch(Exception e) {
     logger.log(e.getMessage(), e); 
 }

La question est:

  1. Est-il une mauvaise pratique (et quelqu'un a eu des problèmes lors de l'ignorer de telles exceptions).
  2. Quand Connection.close() ne jeter aucune exception.
  3. Si il est mauvais, comment dois-je traiter l'exception.

Commentaire:

Je sais que le rejet des exceptions est mal, mais je suis se rapportant uniquement à des exceptions générées lors de la fermeture d'une connexion (et que j'ai vu c'est assez commun dans ce cas).

Personne ne sait quand Connection.close() peut jeter quoi que ce soit?

source d'informationauteur jb.

  1. 12

    En fait, ce que vous faites est (presque) bonne pratique 🙂 voici ce que j'ai vu dans le Printemps JdbcUtils.java. Donc, vous voudrez peut-être ajouter
    un autre bloc Catch.

    /**
 * Close the given  ResultSet and ignore any thrown exception.
 * This is useful for typical finally blocks in manual  code.
 * @param resultSet the  ResultSet to close
 * @see javax.resource.cci.ResultSet#close()
 */
private void closeResultSet(ResultSet resultSet) {
  if (resultSet != null) {
    try {
      resultSet.close();
    }
    catch (SQLException ex) {
      logger.debug("Could not close  ResultSet", ex);
    }
    catch (Throwable ex) {
      //We don't trust the  driver: It might throw RuntimeException or Error.
      logger.debug("Unexpected exception on closing  ResultSet", ex);
    }
  }
}
  2. 12

    En général, j'ai eu des jours gaspillée par des gens jeter des exceptions comme ça.

    Je vous recommande de suivre quelques règles de base avec des exceptions:

    Si vous êtes ABSOLUMENT SÛR que vous ne sera JAMAIS la cause d'un problème avec un contrôle exception, attraper JUSTE que l'exception et commentaire exactement pourquoi vous n'avez pas besoin de le gérer. (Le sommeil déclenche une InterruptedException qui peut toujours être ignorés, sauf si vous êtes réellement intéressé à elle, mais honnêtement ce n'est le cas que j'ai l'habitude de les ignorer-même à qui, si vous n'obtenez jamais, quel est le coût de l'exploitation forestière?)

    Si vous n'êtes pas sûr, mais vous pouvez obtenir de temps en temps, capturer et enregistrer une trace de la pile juste de sorte que, si elle est à l'origine du problème, il peut être trouvé. Encore une fois, attraper l'exception que vous devez.

    Si vous ne voyez pas de toute façon l'objet d'une exception peut être lancée, l'attraper et de re-jeter un décoché exception.

    Si vous savez exactement ce qui est à l'origine de l'exception, de l'attraper et de journaux exactement pourquoi, vous n'avez pas vraiment besoin d'une trace de la pile dans ce cas, si vous êtes très clairement ce qui en est la cause (et vous pouvez mentionner la classe de l'enregistrement si vous n'êtes pas déjà l'utilisation de log4j ou quelque chose.

    Il semble que votre problème serait tomber dans la dernière catégorie, et pour ce genre de catch, ne jamais faire ce que vous avez écrit (Exception e), c'est toujours l'exception spécifique au cas où certains décoché exception est levée (mauvais paramètres, pointeur null, ...)

    Mise à jour: Le principal problème ici est que les Exceptions sont ungood. Le seul très utilisé un langage qu'ils existent dans l'est de Java. Ils sont soignées en théorie, mais dans l'action, ils l'origine de ce comportement de prise et de cacher que vous n'avez pas décoché les exceptions.

    Beaucoup de gens ont commenté le fait que j'ai dit que les cacher est correct, parfois. Pour être plus précis, le seul cas que je peux penser est:

    try {
    Thread.sleep(1000);
catch (InterruptedException e) {
    //I really don't care if this sleep is interrupted!
}

    Je suppose que la principale raison je sens que cette utilisation est d'accord c'est parce que cette utilisation de InterruptedException est un abus de l'objet d'une exception patron en premier lieu, il communique le résultat d'un sommeil plus que d'indiquer une exception condition.

    Il aurait fait beaucoup plus de sens:

    boolean interrupted=Thread.sleep(1000);

    Mais ils étaient très fiers de leur nouveau vérifié exception de modèle quand ils ont d'abord créé Java (ce qui est compréhensible, c'est vraiment génial dans le concept-seulement échoue dans la pratique)

    Je ne peux pas imaginer un autre cas où c'est acceptable, alors peut-être que je devrais avoir listé ce que la seul cas où il est peut-être valable pour ignorer une exception.

  3. 6

    Au minimum, toujours toujours toujours journal des exceptions que vous attraper et de ne pas agir.

    Silencieusement pris des exceptions qui sont avalés sans la moindre peep sont les pires.

  4. 3

    Personnellement, j'aime bien ta deuxième idée de l'enregistrement de l'erreur. Parce que vous êtes capture d'Exception, il est théoriquement possible de prendre autre chose qu'une Exception SQL. Je ne suis pas sûr de ce qui pourrait se passer ou comment rares (comme de la mémoire des exceptions, etc), mais supressing toutes les erreurs ne semble pas juste pour moi.

    Si vous souhaitez supprimer les erreurs, je le ferais seulement de ceux que vous connaissez doit être traitée de cette façon.

    Hypothecial situation: que faire si votre sql eu une transaction ouverte, et la fermeture de la connexion a provoqué une exceptino à cause de cela, voulez-vous de supprimer cette erreur? Même la suppression de SQLExceptions peut-être un peu dangereux.

  5. 1

    Vous avez à gérer l'exception. Ce n'est pas une mauvaise pratique. Imaginez-vous perdu du réseau juste avant la fermeture de la dabatase connexion. Il sera probablement jeter l'exception.

    Est-il rare ? Oui. Je suppose que c'est ce qu'ils sont appelés des exceptions et ce n'est pas une raison pour l'ignorer. N'oubliez pas que si elle peut échouer, ce sera un échec.

    Vous devez également penser à savoir si il est possible d'avoir une valeur null connexion à ce stade, (il serait la cause d'une exception NullPointerException) ou pas.

    if (connection != null) {
   try { 
      connection.close(); 
   } catch (SQLException sqle) { 
      logger.log(e.getMessage(), e); 
   }
}
  6. 1

    Dans un monde idéal, vous ne devriez jamais ne rien faire sur une exception, bien sûr, dans un monde idéal, vous ne serait jamais obtenir une exception, soit 😎

    Donc, vous avez à examiner les impacts des différentes options.

    Journal seulement: opérations de Base de données sont tous finis, rien à faire, mais nettoyer les ressources. Si une exception se produit à ce stade, il est probable qu'il n'a pas d'impact sur le travail effectué, de sorte que l'enregistrement de l'erreur devrait suffire. Bien sûr, si une erreur se produit pendant l'enregistrement, alors vous avez essentiellement à la poignée de la base de données a échoué opération qui n'a pas fait échouer.

    Vide gestionnaire: opérations de Base de données sont tous finis, rien à faire, mais nettoyer les ressources. Si une exception se produit à ce stade, il est probable qu'il n'a pas d'impact sur le travail effectué, de sorte que le retour de la méthode avec succès. Le prochain accès de base de données peut s'exécuter dans le même problème, mais il devrait se produire au début d'une transaction, d'où il sera à juste titre échec, puis obtenir de manière appropriée. Si le problème a fixé lui-même, alors il n'y aura aucune indication que quelque chose est allé de mal.

    C'est un joli scénario typique de mettre une close() opération(s) dans un bloc finally pour vous assurer que le nettoyage se produit, puisque nous ne voulons pas d'autres défauts à inhiber la ressource de nettoyage. Si aucune erreur n'est survenue, votre méthode ne devrait pas manquer lors de son opération s'est terminée avec succès. Dans ce cas, vide à l'exception de la manipulation est tout à fait normal.

    Bien sûr, les opinions varient.

  7. 1

    Vous pouvez également jeter un RuntimeException:

    try {
    connection.close();
 } catch(Exception e) {
     throw new RuntimeException(e); 
 }

    Vous n'aurez pas à changer votre méthode de signature et sera en mesure de faire usage de l'Exception.getCause méthode plus tard pour trouver la cause du problème.

  8. 1

    Noter que Apache Commons DButils fournit un closeQuietly() méthode, que vous pouvez utiliser pour éviter d'encombrer votre code avec redondant captures. Notez que je ne dis pas avaler des exceptions, mais pour ce close() scénario, je pense qu'il est généralement acceptable.

  9. 0

    De mon expérience en ignorant une exception n'est jamais une bonne idée.
    Croyez-moi, le soutien à la production ingénieurs et analystes merci une tonne, si vous vous êtes connecté, l'exception.

    Aussi, si vous utilisez le droit de Journalisation, il y aurait zéro ou un impact minimal sur les performances de l'exception.

  10. 0

    si c'est une "erreur qui n'arrive jamais," le cas, alors je vais juste relever une Exception et espère que personne ne l'attrape.

    si c'est le cas de tout autre, je vais probablement journal il

  11. 0

    Si vous pouvez le manipuler, puis le faire (et l'enregistrer si c'était inattendu). Si vous ne pouvez pas le manipuler, puis renvoyer correctement de sorte que certains de code ci-dessus peut s'en occuper.

    Silencieusement à avaler des exceptions laisse des informations cruciales pour la personne à corriger le code.

  12. 0

    Son une meilleure pratique pour gérer l'exception au moment de la fermeture de la connexion à la base de données. Parce que, au plus tard un certain moment dans votre code, si vous essayez d'accéder à l'instruction ou objets resultset alors il sera automatiquement déclencher une exception. Donc, c'est Mieux pour gérer l'exception.