[Session d'étude interne] Gestion des exceptions Java (2017/04/26)

0. Introduction

Personne cible

• Les personnes utilisant Java

Ce que je veux dire

• Différence entre l'exception vérifiée et l'exception d'exécution
• Exception anti-motif

Expliquez les règles concernant les exceptions du point de vue des créateurs d'API et des utilisateurs d'API. L'API (Application Program Interface) suppose une méthode publique.

Livres de référence

Effective Java 2nd Edition

Un livre écrit à l'époque de Java 6, un peu vieux, mais un bon livre. Les règles sont rédigées en mettant l'accent sur la clarté et la concision.

• Cette diapositive cite le texte et les figures de ce livre.
• "Item ~" représente le numéro d'article de ce livre.
• Bien que le terme «exception vérifiée» soit utilisé dans ce livre, le terme «exception vérifiée» est utilisé dans cette diapositive.

table des matières

1. Résumé des exceptions
2. Règles d'exception pour les utilisateurs d'API
3. Règles d'exception pour les auteurs d'API
4. Annexe

1. Résumé des exceptions

Quelles sont les exceptions?

Le traitement d'exception (reigaishori) consiste à suspendre (arrêter) le traitement en cours et à effectuer un autre traitement lorsqu'une anomalie se produit pendant que le programme exécute un certain traitement. L'anomalie qui se produit à ce moment est appelée une exception.

Gestion des exceptions Wikipedia

Exceptions vérifiées et exceptions d'exécution

• Exception vérifiée: une exception qui doit être interceptée ou levée par l'appelant. Une exception qui n'est pas une exception d'exécution.

• Exception Rentime: Une exception que l'appelant n'a pas à vérifier. Hériter de java.lang.RuntimeException.

Structure du type d'exception

java.lang.Exception
 -  IOException
 -  SQLException
 -  RuntimeException
     - NullPointerException
     - IllegalArgumentException

Syntaxe de gestion des exceptions (méthode d'appel à lancer)

Lors de l'utilisation du constructeur de java.io.FileReader.

throws définit l'exception que la méthode lève.

public FileReader(File file) throws FileNotFoundException

Que faire lors de l'appel d'une méthode qui lève une exception

• Exception de capture

try {
  FileReader fr = new FileReader(file);  
} catch(FileNotFoundException e) {
  //...
}

• Lancer une exception Utilisez throws dans les déclarations de méthode.

private void read(File file) throws FileNotFoundException {
    FileReader fr = new FileReader(file);  
}

Syntaxe de gestion des exceptions (lève explicitement Exception)

Utilisez le mot réservé throw.

private void read(File file) {
  if (file == null) {
     throw new NullPointerException("file is null");
  }
}

Les exceptions vérifiées doivent déclarer «throws» dans la méthode. Aucune exception d'exécution (telle que NullPointerException) n'est requise. Une description des exceptions vérifiées et des exceptions d'exécution sera donnée ultérieurement.

Syntaxe de gestion des exceptions (multi-capture)

Disponible à partir de Java 7.

Pour Java 6 ou version antérieure

catch (IOException ex) {
     logger.log(ex);
     throw ex;
} catch (SQLException ex) {
     logger.log(ex);
     throw ex;
}

Pour Java 7 ou version ultérieure

catch (IOException|SQLException ex) {
    logger.log(ex);
    throw ex;
}

https://docs.oracle.com/javase/jp/8/docs/technotes/guides/language/catch-multiple.html Référence

2. Règles d'exception pour les utilisateurs d'API

Ne pas ignorer les exceptions (élément 65)

Ignorer est le pire. Absolument pas.

try {
   ...
} catch(SomeException e) {}

Un bloc catch vide n'atteint pas le but de l'exception. Son but est de "forcer le traitement de conditions exceptionnelles".

Vue personnelle

• Concession 1: Décrivez la raison de l'ignorance dans le commentaire
• Concession 2: Sortie du contenu de l'exception. log.error (" ~ échec ", e);
• Concession 3: Lent pour le moment sans attraper

N'utiliser des exceptions que pour des conditions exceptionnelles (point 57)

Qu'est-ce qui ne va pas? Une exception est utilisée pour déterminer la fin de la boucle.

int[] array = {1,2,3,4,5};
try {
	int i=0;
	while(true) {
		System.out.println(array[i++]);
        //Autre traitement
	}
} catch(ArrayIndexOutOfBoundsException e) {}

• Pas évident. Si vous voulez faire une boucle, la boucle for est plus évidente.
• Les bogues inattendus sont masqués. Que faire si ʻArrayIndexOutOfBoundsException` se produit dans "Autre traitement"?

Les exceptions, comme leur nom l'indique, ne doivent être utilisées que pour des conditions exceptionnelles. Il ne doit jamais être utilisé pour des flux de contrôle normaux.

[Vue personnelle] Catch avec les exceptions appropriées

Je peux l'attraper avec java.lang.Exception, mais je l'attrape avec java.lang.Exception.

File file = new File("/tmp/sample.txt");
try {
  FileReader fr = new FileReader(file);  
} catch(Exception e) { //IOException est approprié
  //...
}

problème

• Je ne sais pas quelle exception je veux attraper.
• Il attrape RuntimeException, qui doit être propagé à la méthode supérieure.

Si vous pouvez l'attraper avec java.lang.Exception

Traitement du cadre, etc. Si vous n'arrêtez pas la propagation d'exception quelque part, votre système (par exemple Tomcat) tombera en panne.

La source suivante est l'endroit où la logique métier est appelée dans le cadre Terasoluna.

java:jp.terasoluna.fw.ex.aop.log.BLogicLogInterceptor.java

 public Object invoke(MethodInvocation invocation) throws Throwable {
       //...
        try {
           //Exécution de la logique métier
            result = invocation.proceed();
        } catch (Throwable e) {
            if (checkException(e)) {
                logger.error(e); //[Sortie d'exception]
                throw e;
            } else {
                logger.debug(e); //[Sortie d'exception]
                throw e;
            }
        }
}        

• Throwable est un niveau supérieur à java.lang.Exception.

[Vue personnelle] La plage des blocs d'essai n'est pas trop large

Le traitement qui ne lève pas d'exception ne doit pas être décrit dans le bloc try si possible.

try {
  //Traitement autre que des fichiers(L'exception n'est pas levée)
  initialize();
  //Traitement lié aux fichiers
  File file = new File("/tmp/sample.txt");
  FileReader fr = new FileReader(file);  
} catch(IOException e) { 
  //...
}

problème

• Il est difficile de dire quelle méthode génère une exception.

3. Règles d'exception pour les auteurs d'API

Utiliser des exceptions d'exécution pour les erreurs de programmation (élément 58)

La plupart des exceptions d'exécution indiquent des violations de conditions préalables. Une violation de condition préalable est que le client API n'adhère tout simplement pas au contrat défini par la spécification API.

Exceptions d'exécution fréquentes

• Ne se produit pas si vous vérifiez l'argument passé à NumberFormatExceptionʻInteger.parseInt () `
• NullPointerException: ne se produit pas si null est coché
• ArrayIndexOutOfRangeException: ne se produit pas si vous vérifiez la taille du tableau

http://qiita.com/yuba/items/d41290eca726559cd743 Référence

Exceptions que les utilisateurs d'API peuvent éviter, responsabilités des utilisateurs d'API.

Utiliser les exceptions vérifiées (exceptions vérifiées) pour les états récupérables (élément 58)

N'utilisez pas d'exceptions cochées pour les situations où l'appelant peut récupérer correctement.

Je ne suis pas sûr de "l'état récupérable".

Selon http://qiita.com/yuba/items/d41290eca726559cd743, "l'exception vérifiée est un système anormal qui n'est pas de la responsabilité de l'appelant."

Exceptions d'inspection fréquemment observées

• IOException: échec du traitement des E / S ou occurrence d'interruption
• SQLException: l'échec de la base de données ne peut pas être évité par l'appelant

Puisqu'il ne peut être évité, l'utilisateur de l'API est obligé de «penser au système anormal».

IOException est-il vraiment inévitable en premier lieu?

Si vous passez un chemin de fichier qui n'existe pas dans le constructeur FileReader, une FileNotFoundException se produira. Même si l'existence du fichier est confirmée, le fichier peut être supprimé immédiatement après cela, de sorte qu'il ne peut pas être complètement évité.

File file = new File("/tmp/sample.txt");
if (file.exists() ){ 
  //Si le fichier est supprimé ici, une exception se produira sur la ligne suivante
  FileReader fr = new FileReader(file);
}  

Mon avis

Si "ce n'est pas la responsabilité de l'utilisateur de l'API", cela ne semble pas être "la responsabilité du créateur de l'API". Peut-être que personne ne peut en prendre la responsabilité.

Le créateur de l'API a estimé qu'il lançait une exception de vérification dans le sens que "même si un système anormal se produit, ce n'est pas ma responsabilité".

Existe-t-il une exception de contrôle même sous la responsabilité de l'utilisateur de l'API?

La méthode java.text.DateFormat # parse lève une exception vérifiée ParseException.

ParseException-Si le début de la chaîne spécifiée ne peut pas être analysé.

SimpleDateFormat sdf = new SimpleDateFormat("yyyy/MM/dd");
try {
	sdf.parse("abc"); //Lancer PrseException
} catch (ParseException e) {
	e.printStackTrace();
}

ʻInteger.parseInt lève une exception d'exécution NumberFormatException. SimpleDateFormat` n'est pas thread-safe et peut lever une exception vérifiée.

[Opinion personnelle] Ne lancez pas java.lang.Exception

/**Lecture de fichiers*/
List<String> read(File file) throws Exception {
  List<String> lines = new ArrayList<>();
  FileReader fr = new FileReader(file);
  //....
  return lines;
}  

problème

• Le contenu de l'exception est trop abstrait. Il dit seulement «anormal».

4. Annexe

Langage C pour lequel il n'y a pas de mécanisme de gestion des exceptions

L'erreur est représentée par une valeur de retour ou un argument de sortie.

/**
 * 0:Succès
 * -1:Erreur d'argument
 * -2:Erreurs liées au fichier
 * /
int read(char *file) {
  //...
}

int sub(char *file) {
  int rtn = read(file);
  return rtn;
}

int main() {
  int rtn = sub(file);
}

problème

• Afin de propager l'erreur au niveau supérieur, il est nécessaire d'écrire un processus pour renvoyer la valeur de retour de l'API inférieure au niveau supérieur.
• Impossible de forcer les utilisateurs de l'API à vérifier les erreurs

Avantages et inconvénients des exceptions d'inspection

Seul Java implémente les exceptions vérifiées dans les principales langues. L'une ou l'autre des exceptions d'inspection est négative.

http://qiita.com/Kokudori/items/0fe9181d8eec8d933c98

enfin clause et retour

Lors du retour dans la clause try-catch-finally, si la clause finally est définie, l'intérieur de la clause finally est toujours exécuté avant le retour.

source-try.java

public class Try {
    public static void main(String[] args) {
        String i=TryCatch();
        System.out.println(i);
    }

    public static String TryCatch(){
        System.out.println("début!");
        String str = null;//Rendre nul
        try{
            str.toString();     //NullPointerException
            System.out.println("Hogehoge");
            return "Le retour de la clause Try.";
        }catch(Exception e){
            System.out.println("Fuga Fuga");
            return "Le retour de la clause Catch.";
        }finally{
            System.out.println("La clause finally a été exécutée.");
        }
    }
}

System.out

début!
Fuga Fuga
La clause finally a été exécutée.
Le retour de la clause Catch.

Extrait de http://qiita.com/eijenson/items/7e9e112e69b37f72353c

Break, continue, return, System.exit sont interdits dans la clause finally

Ceux-ci ne sont pas sujets à des erreurs ou des avertissements lorsqu'ils sont compilés avec javac. Cependant, lorsque j'utilise Eclipse, j'obtiens un avertissement concernant la pause, la poursuite et le retour que "le blocage final ne se termine pas correctement".

Extrait de http://www.atmarkit.co.jp/ait/articles/0611/22/news145.html

public class Try {
    public static void main(String[] args) {
        String i=TryCatch();
        System.out.println(i);
    }

    public static String TryCatch(){
        System.out.println("début!");
        String str = null;//Rendre nul
        try{
            str.toString();     //NullPointerException
            System.out.println("Hogehoge");
            return "Le retour de la clause Try.";
        }catch(Exception e){
            System.out.println("Fuga Fuga");
            return "Le retour de la clause Catch.";
        }finally{
            System.out.println("La clause finally a été exécutée.");
            return "Je serrai l'exception";//Faire un retour
        }
    }
}

System.out

début!
Fuga Fuga
La clause finally a été exécutée.
Je serrai l'exception

try-with-resources

Il peut être utilisé à partir de Java 7. fermer la syntaxe inutile

Avant Java SE 7, vous pouvez utiliser des blocs finally pour vous assurer que les ressources sont fermées, que l'instruction try se termine avec succès ou brusquement.

static String readFirstLineFromFileWithFinallyBlock(String path) throws IOException {
  BufferedReader br = new BufferedReader(new FileReader(path));
  try {
    return br.readLine();
  } finally {
    if (br != null) br.close();
  }
}

Lors de l'utilisation de l'instruction try-with-resources

static String readFirstLineFromFile(String path) throws IOException {
  try (BufferedReader br = new BufferedReader(new FileReader(path))) {
    return br.readLine();
  }
}

Dans cet exemple, la ressource déclarée dans l'instruction try-with-resources est BufferedReader. La déclaration est entre parenthèses immédiatement après le mot-clé try. À partir de Java SE 7, la classe BufferedReader implémente l'interface java.lang.AutoCloseable. L'instance BufferedReader est déclarée avec une instruction try-with-resource, elle se ferme donc indépendamment du fait que l'instruction try s'est terminée avec succès ou brusquement (suite à la levée d'une IOException par la méthode BufferedReader.readLine). Peut être fait.

http://docs.oracle.com/javase/jp/7/technotes/guides/language/try-with-resources.html

«97 choses que les programmeurs devraient savoir» sur les exceptions

[97 choses que les programmeurs devraient savoir](http://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E6%9B%B8%E7%B1%8D/%E3%83%97%E3%83%AD%E3 % 82% B0% E3% 83% A9% E3% 83% 9E% E3% 81% 8C% E7% 9F% A5% E3% 82% 8B% E3% 81% B9% E3% 81% 8D97% E3% 81 % AE% E3% 81% 93% E3% 81% A8)

• [Ne forcez pas le programme à mourir](http://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3 % 82% A4 /% E6% AD% BB% E3% 81% AC% E3% 81% AF% E3% 81% 9A% E3% 81% AE% E3% 83% 97% E3% 83% AD% E3% 82% B0% E3% 83% A9% E3% 83% A0% E3% 82% 92% E7% 84% A1% E7% 90% 86% E3% 81% AB% E7% 94% 9F% E3% 81% 8B% E3% 81% 97% E3% 81% A6% E3% 81% 8A% E3% 81% 84% E3% 81% A6% E3% 81% AF% E3% 81% 84% E3% 81% 91% E3% 81% AA% E3% 81% 84)

• [N'ignorez pas l'erreur](http://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3% 82% A8% E3% 83% A9% E3% 83% BC% E3% 82% 92% E7% 84% A1% E8% A6% 96% E3% 81% 99% E3% 82% 8B% E3% 81% AA)

• [Distinguer clairement les exceptions techniques et commerciales](http://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82 % A4 /% E6% 8A% 80% E8% A1% 93% E7% 9A% 84% E4% BE% 8B% E5% A4% 96% E3% 81% A8% E3% 83% 93% E3% 82% B8% E3% 83% 8D% E3% 82% B9% E4% BE% 8B% E5% A4% 96% E3% 82% 92% E6% 98% 8E% E7% A2% BA% E3% 81% AB% E5% 8C% BA% E5% 88% A5% E3% 81% 99% E3% 82% 8B)

Site de référence

[Bonnes pratiques pour la gestion des exceptions en Java] (https://moneyforward.com/engineers_blog/2014/08/22/java%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E4%BE%8B%E5%A4%96%E5%87%A6%E7%90%86%E3%81%AE%E3%83%99%E3%82%B9%E3%83%88%E3%83%BB%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9/)

Les exceptions vérifiées par Java sont des systèmes anormaux qui ne relèvent pas de la responsabilité de l'appelant

Historique de la gestion des erreurs

Grand péché dans un design exceptionnel

fin