Est-ce que j'utilise correctement Java 7 try-with-resources


Je m'attends à ce que le lecteur en mémoire tampon et le lecteur de fichiers se ferment et que les ressources soient libérées si l'exception est levée.

public static Object[] fromFile(String filePath) throws FileNotFoundException, IOException
{
    try (BufferedReader br = new BufferedReader(new FileReader(filePath)))
    {
        return read(br);
    } 
}

Cependant, est - il nécessaire d'avoir une clause catch pour réussir la clôture?

MODIFIER:

Essentiellement, le code ci-dessus en Java 7 est-il équivalent au code ci-dessous pour Java 6:

public static Object[] fromFile(String filePath) throws FileNotFoundException, IOException
{

    BufferedReader br = null;

    try
    {
        br = new BufferedReader(new FileReader(filePath));

        return read(br);
    }
    catch (Exception ex)
    {
        throw ex;
    }
    finally
    {
        try
        {
            if (br != null) br.close();
        }
        catch(Exception ex)
        {
        }
    }

    return null;
}
Author: yair, 2013-07-15

2 answers

C'est correct et il n'y a pas d'exigence pour la clause catch. Oracle java 7 doc indique que la ressource sera fermée indépendamment de si une exception est réellement levée ou non.

Vous ne devez utiliser une clause catch que si vous souhaitez réagir à l'exception. La clause catch sera exécutée après la ressource est fermée.

Voici un extrait du tutoriel de Oracle:

L'exemple suivant lit la première ligne d'un fichier. Il utilise un instance de BufferedReader pour lire les données du fichier. BufferedReader est une ressource qui doit être fermée après la fin du programme avec il:

static String readFirstLineFromFile(String path) throws IOException {
    try (BufferedReader br =
                   new BufferedReader(new FileReader(path))) {
        return br.readLine();
    }
} // In this example, the resource declared in the try-with-resources statement is a BufferedReader.

... Parce que l'instance BufferedReader est déclarée dans un instruction try-with-resource, elle sera fermée, que ce soit l'instruction try se termine normalement ou brusquement (à la suite de la méthode BufferedReader.readLine lancer un IOException).

MODIFIER

Concernant la nouvelle question modifiée:

Le code de Java 6 exécute le bloc catch puis le bloc finally. Cela fait que les ressources sont toujours potentiellement ouvertes dans le bloc catch.

Dans la syntaxe Java 7, les ressources sont fermées avant le bloc catch, donc les ressources sont déjà fermées pendant l'exécution du bloc catch. Ceci est documenté dans le lien ci-dessus:

Dans un essai avec des ressources instruction, toute capture ou enfin bloc est exécuté après la fermeture des ressources déclarées.

 94
Author: yair, 2015-08-27 09:50:08

Votre utilisation de try-with-resources fonctionnera bien dans ce cas particulier, mais ce n'est pas tout à fait correct en général. Vous ne devriez pas enchaîner les ressources comme ça, car cela peut entraîner des surprises désagréables. Supposons que vous ayez une taille de tampon variable:

public static Object[] fromFile(String filePath) throws FileNotFoundException, IOException
{
    int sz = /* get buffer size somehow */
    try (BufferedReader br = new BufferedReader(new FileReader(filePath), sz))
    {
        return read(br);
    } 
}

Supposons que quelque chose a mal tourné et que vous vous êtes retrouvé avec sz négatif. Dans ce cas, votre ressource de fichier (créée via new FileReader(filePath)) sera ET NON fermée.

Pour éviter ce problème, vous devez spécifier chaque ressource séparément comme ceci:

public static Object[] fromFile(String filePath) throws FileNotFoundException, IOException
{
    int sz = /* get buffer size somehow */
    try (FileReader file = new FileReader(filePath);
         BufferedReader br = new BufferedReader(file, sz))
    {
        return read(br);
    } 
}

, Dans ce cas, même si l'initialisation de br échoue file obtient toujours fermé. Vous pouvez trouver plus de détails ici et ici.

 66
Author: Andrii Polunin, 2014-01-25 09:37:02