B. Liskov, Program Development in Java, chap. 4 Exceptions

Présentation au sujet: "B. Liskov, Program Development in Java, chap. 4 Exceptions"— Transcription de la présentation:

1 B. Liskov, Program Development in Java, chap. 4 Exceptions

2 Objectif Apprendre à manipuler et à documenter systématiquement les exceptions Vers la spécification de programmes

3 Des procédures partielles vers les exceptions
Domaine : arguments doivent en être membres Range: le résultat /** * REQUIRES: n, d > 0 * EFFECTS : returns the greatest common divisor of n and d. */ public static int gcd( int n, int d) Procédure partielle Spécification -> l’appelant doit s’assurer que d > 0 -> l’implémentation peut ignorer ce test

4 Des procédures partielles vers les exceptions
En général, l’usage des procédures partielles est une mauvaise idée car si l’argument n’appartient pas au domaine, le comportement de la procédure est imprévisible (boucle infinie, valeur erronée..) Les erreurs ne seront pas nécessairement détectée immédiatement Difficile à déverminer, source d’erreurs plus graves Les programmes ne sont pas robustes Un programme est robuste s’il continue à se comporter raisonnablement même en présence d’erreurs. Dégradation gracieuse Il continue à fournir des résultats (approximatifs) même en présence d’erreurs Donne un message d’erreur significatif Ne cause pas de dommages aux données persistentes

5 Informer l’appelant d’un problème
Utiliser des procédures totales Informer l’appelant d’un problème /** * REQUIRES: * EFFECTS : if n > 0, returns n! else return 0 */ public static int fact( int n) Utiliser un résultat pour fournir cette information Pas satisfaisant z = x + Num.fact(y) est valide quelque soit y Int r = Num.fact(y) If (r > 0) z = x + r; else … Il n’y a peut-être pas de valeur disponible, new Vector().get(i) Lancer une exception Approche qui permet de donner de l’information sur les situations non usuelles dans tous les cas.

6 Mécanisme des exceptions
Distinguer les situations non usuelles des situations normales Les séparer du flot normal de contrôle

7 Spécifications Signature : throws liste_exceptions;
Description dans la clause EFFECTS /** * EFFECTS : if “n” is non-positive, throws NonPositiveException, * else returns the factorial of “n” */ public static int fact (int n) throws NonPositiveException

8 Spécifications et exceptions
Lorsqu’une procédure a des effets de bords, il faut expliquer clairement quel est l’effet des exceptions sur ceux-ci Les modifications doivent être décrites explicitement dans chaque cas où elles se produisent; si aucune modification n’est décrite, cela indique qu’il n’y en a aucune. /** * REQUIRES: all elements of “v” are Integers * MODIFIES: v * EFFECTS : if “v” is null, throws NullPointerException, * if “v” contains an element larger than “x” throws NotSmallException; * else add ”x” to “v” */ public static void addMax (Vector v, Integer x) throws NullPointerException, NotSmallException « v » est modifié seulement si la procédure se termine normalement

9 Hiérarchie des exceptions
Throwable Exception Error An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch e.g. VirtualMachineError RuntimeException checked exception (uncheckedException) Checked exception: L’exception doit être énumérée dans la signature de la méthode L’appelant doit la traiter obligatoirement sinon erreur de compilation, e.g. PropertyVetoException Unchecked exception : l’exception n’a pas besoin d’apparaître dans la signature Le compilateur ne vérifie pas si l’appelant traite l’exception, e.g. ClassCastException Pour les spécifications, toutes les exceptions (checked et unchecked) doivent apparaître dans la signature

10 Définition des exceptions
public class NonPositiveIntegerException extends Exception { public NonPositiveIntegerException() { super();} public NonPositiveIntegerException(String arg0) { super(arg0); } public NonPositiveIntegerException(String arg0, Throwable arg1) { super(arg0, arg1); } public NonPositiveIntegerException(Throwable arg0) { super(arg0); Convention : le nom de la classe se termine par exception Bonne pratique : définir un package qui regroupe les exceptions A throwable contains a snapshot of the execution stack of its thread at the time it was created. a message string that gives more information about the error. a cause: another throwable that caused this throwable to get thrown. The cause facility is new in release 1.4. It is also known as the chained exception facility, as the cause can, itself, have a cause, and so on, leading to a "chain" of exceptions, each caused by another

11 Lancer, capturer, propager les exceptions
Lancer une exception If (n < 0) throws new NotPositiveException(« Num.fact »); try … catch … finally L’exception, si elle n’est pas capturée dans la procédure appelante, sera automatiquement propagée à l’appelant de l’appelant si La classe de l’exception ou aucune de ses superclasses n’est énumérée dans l’entête de la procédure appelante Ou si la classe de l’exception hérite de RuntimeException

12 //TCP client makes connection to server, sends request and receives reply
import java.net.*; import java.io.*; public class TCPClient { public static void main (String args[]) { // arguments supply message and hostname of destination Socket s = null; try{ int serverPort = 7896; s = new Socket(args[1], serverPort); DataInputStream in = new DataInputStream( s.getInputStream()); DataOutputStream out = new DataOutputStream( s.getOutputStream()); out.writeUTF(args[0]); // UTF is a string encoding String data = in.readUTF(); System.out.println("Received: "+ data) ; }catch (UnknownHostException e) { System.out.println("Sock:"+e.getMessage()); }catch (EOFException e){System.out.println("EOF:"+e.getMessage()); }catch (IOException e){System.out.println("IO:"+e.getMessage());} }finally {if(s!=null) try {s.close();} catch (IOException e) {System.out.println("close:"+e.getMessage());}} }

13 Design Quand utiliser une exception?
Quel type d’exception utiliser (checked ou unchecked)? Exception =/= erreur Un mécanisme pour attirer l’attention de l’appelant sur un cas particulier L’élément recherché n’est pas dans la liste Une exception à un niveau peut correspondre à un cas normal à l’autre IndexOutOfRangeException -> Fin de boucle au niveau supérieur Pas toutes les erreurs qui mènent à des exceptions Enregistrement erroné  sauter l’enregistrement et continuer Doit être documenté le cas échéant dans la spécification

14 Quand utiliser les exceptions ?
Pour éliminer les contraintes des clauses REQUIRES Ces contraintes ne devraient demeurer que pour des raisons d’efficacité Ex.: searchSorted si le contexte d’utilisation est tellement limité que l’on peut être assuré que ces contraintes seront respectées Pour éviter d’encoder de l’information dans des résultats Ne pas rendre -1, mais lancer une exception Rendre une valeur encodant une telle information serait par contre acceptable dans un contexte d’utilisation très local

15 Checked vs unckecked exceptions ?
Checked exception Ces exceptions doivent être traitées dans l’appelant ou déclarées dans la clause throws Une certaine protection est assurée par le compilateur

16 Checked vs unckecked exceptions ?
Unchecked exception Implicitement propagée vers l’appelant Ne pas s’appuyer sur le code (qui devrait éventuellement être écrit) pour tenir compte des erreurs de programmation L’exception peut être capturée par inadvertance try { x=y[n]; i = Arrays.search(z, x); } catch (indexOutOfBoundsException e) { // handle IndexOutOfBoundsException from use of array « y » // code continues assuming problem has been fixed D’où vient le problème ? Celui de y[n] ou celui de search ? La source d’une erreur ultérieure peut devenir très difficile à retracer

17 Checked vs unckecked exceptions ?
Utiliser les exception unchecked Seulement si On s’attend à ce que les programmeurs vont écrire du code qui va assurer que l’exception ne surviendra pas parce que Il existe une façon pratique et peu coûteuse d’éviter l’exception IndexOutOfBounds Le contexte d’utilisation est local Autrement utiliser les exception checked

18 Programmation défensive
Écrire chaque procédure pour qu’elle se protège des erreurs Source d’erreurs Autres procédures Matériel L’usager Un moyen de donner de l’information sur les erreurs sans encombrer le flot normal d’exécution