jette une exception dans les blocs finalement

Existe-t-il une manière élégante de gérer les exceptions qui sont lancées en finallybloc?

Par exemple:

try {
  // Use the resource.
}
catch( Exception ex ) {
  // Problem with the resource.
}
finally {
   try{
     resource.close();
   }
   catch( Exception ex ) {
     // Could not close the resource?
   }
}

Comment éviter le try/ catchdans le finallybloc?

Je le fais généralement comme ceci:

try {
  // Use the resource.
} catch( Exception ex ) {
  // Problem with the resource.
} finally {
  // Put away the resource.
  closeQuietly( resource );
}

Autre part:

protected void closeQuietly( Resource resource ) {
  try {
    if (resource != null) {
      resource.close();
    }
  } catch( Exception ex ) {
    log( "Exception during Resource.close()", ex );
  }
}

J'utilise généralement l'une des closeQuietlyméthodes suivantes org.apache.commons.io.IOUtils:

public static void closeQuietly(OutputStream output) {
    try {
        if (output != null) {
            output.close();
        }
    } catch (IOException ioe) {
        // ignore
    }
}

Si vous utilisez Java 7 et resourceimplémentez AutoClosable, vous pouvez le faire (en utilisant InputStream comme exemple):

try (InputStream resource = getInputStream()) {
  // Use the resource.
}
catch( Exception ex ) {
  // Problem with the resource.
}

Sans doute un peu exagéré, mais peut-être utile si vous laissez les exceptions bouillonner et que vous ne pouvez rien enregistrer à partir de votre méthode (par exemple, parce que c'est une bibliothèque et que vous préférez laisser le code appelant gérer les exceptions et la journalisation):

Resource resource = null;
boolean isSuccess = false;
try {
    resource = Resource.create();
    resource.use();
    // Following line will only run if nothing above threw an exception.
    isSuccess = true;
} finally {
    if (resource != null) {
        if (isSuccess) {
            // let close throw the exception so it isn't swallowed.
            resource.close();
        } else {
            try {
                resource.close();
            } catch (ResourceException ignore) {
                // Just swallow this one because you don't want it 
                // to replace the one that came first (thrown above).
            }
        }
    }
}

MISE À JOUR: J'ai examiné cela un peu plus et j'ai trouvé un excellent article de blog de quelqu'un qui a clairement pensé à cela plus que moi: http://illegalargumentexception.blogspot.com/2008/10/java-how-not-to-make -mess-of-stream.html Il va encore plus loin et combine les deux exceptions en une seule, ce que je pourrais voir utile dans certains cas.

À partir de Java 7, vous n'avez plus besoin de fermer explicitement les ressources dans un bloc finally à la place, vous pouvez utiliser try la syntaxe -with-resources. L'instruction try-with-resources est une instruction try qui déclare une ou plusieurs ressources. Une ressource est un objet qui doit être fermé une fois que le programme en a terminé avec elle. L'instruction try-with-resources garantit que chaque ressource est fermée à la fin de l'instruction. Tout objet qui implémente java.lang.AutoCloseable, qui inclut tous les objets qui implémentent java.io.Closeable, peut être utilisé comme ressource.

Supposons le code suivant:

try( Connection con = null;
     Statement stmt = con.createStatement();
     Result rs= stmt.executeQuery(QUERY);)
{  
     count = rs.getInt(1);
}

Si une exception se produit, la clôture méthode sera appelée sur chacune de ces trois ressources dans l'ordre inverse dans lequel elles ont été créées. Cela signifie que la méthode close serait appelée en premier pour ResultSetm puis pour Statement et à la fin pour l'objet Connection.

Il est également important de savoir que toutes les exceptions qui se produisent lorsque les méthodes close sont automatiquement appelées sont supprimées. Ces exceptions supprimées peuvent être récupérées par la méthode getsuppressed () définie dans la classe Throwable .

Source: https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

Ignorer les exceptions qui se produisent dans un bloc «finalement» est généralement une mauvaise idée à moins que l'on ne sache quelles seront ces exceptions et quelles conditions elles représenteront. Dans le try/finallymodèle d'utilisation normal , le trybloc place les choses dans un état auquel le code extérieur ne s'attendra pas, et lefinally bloc restaure l'état de ces choses à ce que le code extérieur attend. Le code extérieur qui intercepte une exception s'attendra généralement à ce que, malgré l'exception, tout ait été restaurénormalEtat. Par exemple, supposons que du code démarre une transaction et tente ensuite d'ajouter deux enregistrements; le bloc "finalement" effectue une opération "rollback si non validée". Un appelant peut être préparé à ce qu'une exception se produise lors de l'exécution de la deuxième opération "ajouter" et peut s'attendre à ce que s'il détecte une telle exception, la base de données sera dans l'état où elle était avant que l'une ou l'autre des opérations ne soit tentée. Si, cependant, une deuxième exception se produit pendant la restauration, de mauvaises choses peuvent se produire si l'appelant émet des hypothèses sur l'état de la base de données. L'échec de la restauration représente une crise majeure - une crise qui ne devrait pas être interceptée par le code en s'attendant à une simple exception «Échec d'ajout d'enregistrement».

Mon inclination personnelle serait d'avoir une méthode enfin pour attraper les exceptions qui se produisent et les envelopper dans une "CleanupFailedException", en reconnaissant qu'un tel échec représente un problème majeur et qu'une telle exception ne doit pas être prise à la légère.

Une solution, si les deux exceptions sont deux classes différentes

try {
    ...
    }
catch(package1.Exception err)
   {
    ...
   }
catch(package2.Exception err)
   {
   ...
   }
finally
  {
  }

Mais parfois, vous ne pouvez pas éviter cette deuxième tentative. par exemple pour fermer un flux

InputStream in=null;
try
 {
 in= new FileInputStream("File.txt");
 (..)// do something that might throw an exception during the analysis of the file, e.g. a SQL error
 }
catch(SQLException err)
 {
 //handle exception
 }
finally
 {
 //at the end, we close the file
 if(in!=null) try { in.close();} catch(IOException err) { /* ignore */ }
 }

Pourquoi voulez-vous éviter le blocage supplémentaire? Puisque le bloc finally contient des opérations "normales" qui peuvent lever une exception ET que vous voulez que le bloc finally s'exécute complètement, vous DEVEZ intercepter les exceptions.

Si vous ne vous attendez pas à ce que le bloc finally lève une exception et que vous ne savez pas comment gérer l'exception de toute façon (vous ne feriez que vider la trace de la pile), laissez l'exception remonter la pile des appels (supprimez le try-catch du bloquer).

Si vous voulez réduire le typage, vous pouvez implémenter un bloc try-catch externe "global", qui capturera toutes les exceptions levées dans les blocs finally:

try {
    try {
        ...
    } catch (Exception ex) {
        ...
    } finally {
        ...
    }

    try {
        ...
    } catch (Exception ex) {
        ...
    } finally {
        ...
    }

    try {
        ...
    } catch (Exception ex) {
        ...
    } finally {
        ...
    }
} catch (Exception ex) {
    ...
}

Après beaucoup de réflexion, je trouve le code suivant le meilleur:

MyResource resource = null;
try {
    resource = new MyResource();
    resource.doSomethingFancy();
    resource.close(); 
    resource = null;  
} finally {
    closeQuietly(resource)
}

void closeQuietly(MyResource a) {
    if (a!=null)
        try {
             a.close();
        } catch (Exception e) {
             //ignore
        }
}

Ce code garantit ce qui suit:

1. La ressource est libérée lorsque le code est terminé
2. Les exceptions levées lors de la fermeture de la ressource ne sont pas consommées sans leur traitement.
3. Le code n'essaye pas de fermer la ressource deux fois, aucune exception inutile ne sera créée.

Si vous le pouvez, vous devez tester pour éviter la condition d'erreur pour commencer.

try{...}
catch(NullArgumentException nae){...}
finally
{
  //or if resource had some useful function that tells you its open use that
  if (resource != null) 
  {
      resource.Close();
      resource = null;//just to be explicit about it was closed
  }
}

De plus, vous ne devriez probablement attraper que des exceptions dont vous pouvez récupérer, si vous ne pouvez pas récupérer, laissez-le se propager au niveau supérieur de votre programme. Si vous ne pouvez pas tester une condition d'erreur, vous devrez entourer votre code d'un bloc try catch comme vous l'avez déjà fait (même si je recommanderais toujours de détecter les erreurs spécifiques attendues).

Vous pouvez refactoriser cela dans une autre méthode ...

public void RealDoSuff()
{
   try
   { DoStuff(); }
   catch
   { // resource.close failed or something really weird is going on 
     // like an OutOfMemoryException 
   }
}

private void DoStuff() 
{
  try 
  {}
  catch
  {
  }
  finally 
  {
    if (resource != null) 
    {
      resource.close(); 
    }
  }
}

Je fais généralement ceci:

MyResource r = null;
try { 
   // use resource
} finally {   
    if( r != null ) try { 
        r.close(); 
    } catch( ThatSpecificExceptionOnClose teoc ){}
}

Justification: Si j'en ai fini avec la ressource et que le seul problème que j'ai est de la fermer, je ne peux pas y faire grand-chose. Cela n'a pas de sens non plus de tuer tout le fil si j'en ai fini avec la ressource de toute façon.

C'est l'un des cas où, du moins pour moi, il est prudent d'ignorer cette exception vérifiée.

À ce jour, je n'ai eu aucun problème à utiliser cet idiome.

try {
    final Resource resource = acquire();
    try {
        use(resource);
    } finally {
        resource.release();
    }
} catch (ResourceException exx) {
    ... sensible code ...
}

Travail accompli. Aucun test nul. Prise unique, comprend les exceptions d'acquisition et de libération. Bien sûr, vous pouvez utiliser l'idiome Execute Around et ne devez l'écrire qu'une seule fois pour chaque type de ressource.

Passer Resourcede la meilleure réponse àCloseable

Streams implémente CloseableAinsi, vous pouvez réutiliser la méthode pour tous les flux

protected void closeQuietly(Closeable resource) {
    if (resource == null) 
        return;
    try {
        resource.close();
    } catch (IOException e) {
        //log the exception
    }
}

J'ai rencontré une situation similaire où je ne pouvais pas utiliser try avec des ressources, mais je voulais également gérer l'exception provenant de la fermeture, pas seulement la journaliser et l'ignorer comme le fait le mécanisme closeQuietly. dans mon cas, je n'ai pas vraiment affaire à un flux de sortie, donc l'échec à la fermeture est plus intéressant qu'un simple flux.

IOException ioException = null;
try {
  outputStream.write("Something");
  outputStream.flush();
} catch (IOException e) {
  throw new ExportException("Unable to write to response stream", e);
}
finally {
  try {
    outputStream.close();
  } catch (IOException e) {
    ioException = e;
  }
}
if (ioException != null) {
  throw new ExportException("Unable to close outputstream", ioException);
}