[JAVA] catch (Exception e) ou catch (IOException e) n'est pas requis dans la syntaxe try-with-resources

Syntaxe Try-with-Resources qui garantit un appel close ()

Traitement Close () écrit à l'aide de try-finally comme suit dans Java 6 ou version antérieure

Closeable r = null;
try {
  //Sécuriser les ressources
  r = getResource();
  //Utiliser les ressources
  r.use();
} finally {
  if (r != null) r.close();
}

Cependant, à partir de Java 7, il est devenu très intelligent avec le style d'écriture suivant.

//Sécuriser les ressources
try (Closeable r = getResource()) {
  //Utiliser les ressources
  r.use();
}

Vous connaissez la syntaxe try-with-resources.

Closeable.close () lance ʻIOException`

Maintenant, avec le fragment de code ci-dessus, lorsque vous essayez la programmation réelle, vous remarquerez que certains points importants sont omis. Oui, il ne gère pas le lancement de ʻIOException. En particulier, ce dernier code utilisant la syntaxe try-with-resources, ni getResource ()ni ʻuse ()ne lancent ʻIOException, mais dans l'ensemble, ʻIOException. Parce qu'il y a un appel close (), qui n'est pas visible dans la syntaxe sucrée. close () lance ʻIOException` et nous devons le gérer.

Donc ce dernier est en fait

//Sécuriser les ressources
try (Closeable r = getResource()) {
  //Utiliser les ressources
  r.use();
} catch (IOException e) {
  //Traitement approprié
}

Cela doit être sous la forme de. Ou le lancez-vous plus haut avec jette IOException? Dans tous les cas, le code sera un peu plus bruyant que ce que vous attendiez de la touche d'origine. Jusqu'à présent, si vous avez utilisé la syntaxe try-with-resources une seule fois, vous l'avez probablement déjà remarqué.

Vous pouvez écrire close () qui ne lance pas ʻIOException`

Maintenant, le sujet principal est d'ici. Vous pouvez créer le code simple suivant sans utiliser catch ou throws.

//Sécuriser les ressources
try (MyResource r = getResource()) {
  //Utiliser les ressources
  r.use();
}

Il est possible d'avoir une classe Closeable / ʻAutoCloseable où close ()réussira toujours. Ainsi, lors de l'implémentation deCloseable` lors de la création d'une telle classe par moi-même

public class MyResource implements Closeable {
  public void close() {
    //Fermer le processus qui réussit toujours
  }
}

Et écrivez close () sans throws IOException. L'implémentation de l'interface est valide sans throws IOException. Et si cette classe est une ressource

//Sécuriser les ressources
try (MyResource r = getResource()) {
  //Utiliser les ressources
  r.use();
}

Ne lèvera pas une exception de vérification.

Il est naturel de le remarquer, mais lors de l'utilisation de l'EDI, throws IOException est automatiquement décrit depuis le début, donc il est laissé attaché même s'il n'est pas nécessaire, et par conséquent, catch inutile est forcé. Il semble que ce soit rare, donc même un avertissement.