Discussion :

[vbrabant]

Aujourd'hui :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
try {
  doable.doit(); // Throws several types
} catch (Throwable ex) {
  logger.log(ex);
  throw ex; // Error: Throwable not declared
}

Demain :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
try {
  doable.doit(); // Throws several types
} catch (final Throwable ex) {
  logger.log(ex);
  throw ex; // OK: Throws the same several types
}

[OButterlin]

Non, je n'aime pas le principe... je préfère devoir ajouter un throws Exception à ma méthode pour être certain que celui qui l'appel est conscient du problème...

[bobuse]

Là, je suis un peu perplexe. Car il faut prendre en compte la prop 7. Si on peut catcher plusieurs types d'exception, on peut alors écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
try {
  doable.doit(); // Throws ExceptionType1 or ExceptionType2
} catch (ExceptionType1, ExceptionType2 : ex) {
  logger.log(ex);
  throw ex; // OK, because ExceptionType1 and ExceptionType2 are already declared
}

Vous me suivez ?
Qu'en pensez-vous ?

[bulbo]

Contre,

je vois pas bien l'intérêt ni l'application ..

Cela veut-il dire que des exceptions non Runtime pourraient être "throwée" (dieu du français pardonnez moi ) sans déclaration préalable dans la signature de la méthode ?

Je veux bien que le compilo ajoute le throws a la signature automatiquement mais jusqu'a nouvel ordre je ne suis pas un compilo, je le vois comment moi ce truc ? En parcourant tout le code de chaque méthode a chaque fois ? Et la javadoc dans tout ça ?

Bulbo

[eclesia]

Contre, idem que bulbo.

[bobuse]

Cela veut-il dire que des exceptions non Runtime pourraient être "throwée" (dieu du français pardonnez moi ) sans déclaration préalable dans la signature de la méthode ?

Pas du tout !

Je pense que vous n'avez pas bien compris, ou alors c'est moi

Je reformule l'exemple avec plus de détail.

Avant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public void myMethod(String prefix, String suffix) throws Throwable {
  try {
    File.createTempFile(prefix, suffix);
    // Could throw IllegalArgumentException, IOException or SecurityException
  } catch (Throwable ex) {
    logger.log(ex);
    throw ex; // myMethod could throw a Throwable
  }
}

Après :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public void myMethod(String prefix, String suffix) throws IOException {
  try {
    File.createTempFile(prefix, suffix);
    // Could throw IllegalArgumentException, IOException or SecurityException
  } catch (Throwable ex) {
    logger.log(ex);
    throw ex;
  }
}

Sachant que dans mon exemple, IllegalArgumentException et SecurityException n'ont pas besoin d'être déclarée en throws car elles sont des RuntimeException. Mais elles seront cependant interceptées dans le catch.

Est-ce que mon exemple convient ?

[bulbo]

Je pense que vous n'avez pas bien compris, ou alors c'est moi

Je reformule l'exemple avec plus de détail.

Avant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public void myMethod(String prefix, String suffix) throws Throwable {
  try {
    File.createTempFile(prefix, suffix);
    // Could throw IllegalArgumentException, IOException or SecurityException
  } catch (Throwable ex) {
    logger.log(ex);
    throw ex; // myMethod could throw a Throwable
  }
}

Après :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public void myMethod(String prefix, String suffix) throws IOException {
  try {
    File.createTempFile(prefix, suffix);
    // Could throw IllegalArgumentException, IOException or SecurityException
  } catch (Throwable ex) {
    logger.log(ex);
    throw ex;
  }
}

Sachant que dans mon exemple, IllegalArgumentException et SecurityException n'ont pas besoin d'être déclarée en throws car elles sont des RuntimeException. Mais elles seront cependant interceptées dans le catch.

Est-ce que mon exemple convient ?

Ton exemple est construit pour marcher alors forcément il te convient

Bon du coup j'ai relu l'exemple, et un exemple que je dois relire 3 fois pour en comprendre le fonctionnement me laisse a penser que la maintenance de ce genre de trucs risque d'être piégeuse..

Je pense que la methode englobante (et que l'on ne voit pas dans l'exemple, pourtant ça aurait aidé) déclare les throws des "several type" mais pas de Throwable, ce qui explique qu'aujourd'hui on soit obligé d'écrire un catch pour chaque type d'exception pour faire la même chose.

Maintenant que va-t'il se passer si une exception non déclarée dans le throws arrive ? Le compilo saura que ce n'est pas bon et pourra indiquer que telle exception doit être catchée ? Ou bien l'exception sera rethrowée () et on aura un crash au runtime ?

Ca manque de précision; dans le cas ou le compilo retrouve ses petits c'est bon pour moi sinon a proscrire absolument.

Bulbo

[elitost]

Pour cette évolution, même si il faut bien faire attention au mot clé final, peut être ambigu dans la lecture

[bouye]

Pour, j'ai ai marre d'initialiser de nouvelles exceptions et de les chainer a la precedente avec initCause() a chaque fois.

[woodwai]

J'ai voté contre car je pense que ça permettrais une gestion plus laxiste des exception et que c'est mauvais.

Par contre, en lisant les différents messages je me pose des question quand à la compréhension, donc si l'auteur original, vbrabant, pouvait un peu plus expliquer ce serait sympa.

[bobuse]

Effectivement, la proposition peut être mal comprise, et laisser à penser à du laxisme.
Je pense que c'est la notation qui n'est pas très explicite. Qu'est-ce qu'on pourrait trouver de mieux ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

catch (? extends Throwable ex)

Bof

Encore une fois, le problème ne se poserait pas avec la proposition 7, et ce serait beaucoup moins ambigü !!

[adiGuba]

Un petit contre, non pas contre la proposition mais contre la syntaxe qui est incompréhensible à mon avis...

D'ailleurs je pense que certain ne l'on pas bien compris...



En fait il ne s'agit pas réellement d'un vrai catch puisqu'on laisse remonter les exception à chaque fois. Il s'agit plus d'un "filtre" qui permettrait de voir passer les exceptions juste avant de les remonter, par exemple pour les logger.


Imaginer une méthode toute simple qui pourrait remonter des IOException :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
	public void method() throws IOException {
		method1(); // throws IOException
		method2();
	}

Comme toutes méthodes elle peut également remonter des RuntimeException (NullPointerException par exemple) ou des Error (OutOfMemory).



Maintenant si vous voulez rajouter un log au sein de cette méthode juste pour conserver une trace des problèmes rencontré tout en continuant à les remonter, il vous faut traiter chaque cas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
	public void method() throws IOException, SQLException {
		try {
			method1(); // throws IOException
			method2();
		} catch (IOException e) {
			log("...");
			throw e;
		} catch (RuntimeException e) {
			log("...");
			throw e;
		} catch (Error e) {
			log("...");
			throw e;
		}
	}

Cette proposition vise à permet cela plus simplement, en utilisant un catch unique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
	public void method() throws IOException {
		try {
			method1(); // throws IOException
			method2();
		} catch (final Throwable t) {
			log("...");
			throw t;
		}
	}

En fait ce catch là ne traite pas les exceptions et les laisse remonter, mais ce code ne marche pas car Throwable pourrait correspondre à n'importe quoi, or dans ce cas précis ce ne peut être qu'une IOException, une RuntimeException ou une Error ce qui est parfaitement compatible avec la déclaration de notre méthode...



Bref ce bloc catch ne correspond qu'à un simple passage pour l'exception qui sera quand même remonté... et du coup la syntaxe ne me plait pas.
J'opterais plutôt pour ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
	public void method() throws IOException, SQLException {
		try {
			method1(); // throws IOException
			method2();
		} catch (Throwable t) {
			// Toutes les exceptions qui arrive ici seront
			// remonté après l'exécution de ce bloc :
			log("...");
		}
	}

Ici le bloc throws() est exécuté lorsqu'un élément est remonté, mais cela ne traite pas l'exception. Ainsi si le bloc remonte une exception qui n'est pas propagé par la méthode il y aura une erreur et il faudra la catcher normalement, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
	public void method() throws IOException, SQLException {
		try {
			method1(); // throws IOException
			method2(); // throws SQLException
			method3();
		} catch (SQLException e) {
			log("...");
			throw new IOException("SQL Error");
		} catch (Throwable t) {
			// Toutes les exceptions qui arrive ici seront
			// remonté après l'exécution de ce bloc :
			log("...");
		}
	}

a++

[Alec6]

Contre

perte de sémantique;

La sémantique n'est elle pas la voie de la sagesse.

Par contre un truc qui manque peut etre à JAVA c'est la possibilité d'écrire un listener d'exception. Pour les évènements java swing on branche un AWTEventListener sur le toolkit ce qui permet de tracer les actions utilisateurs (pour faire de la recherche en ergonomie, du debuggage, et des graphe fonctionnels... c'est super pratique).

Je crois pas qu'on peut faire pareil avec les Exception. Si c'était possible on pourrait centraliser les log4J (je fais un appel dans le constructeur pour ma part).

[bobuse]

J'opterais plutôt pour ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
	public void method() throws IOException, SQLException {
		try {
			method1(); // throws IOException
			method2();
		} throws (Throwable t) {
			// Toutes les exceptions qui arrive ici seront
			// remonté après l'exécution de ce bloc :
			log("...");
		}
	}

Ouais. Moi j'aime bien l'idée. Ça paraît effectivement plus clair
Reste à discuter si « throws » et le bon terme, mais je trouve que l'idée est la bonne.

[imad.elghazoini]

Contre, le code deviendra incomprehensible

[FreshVic]

J'ai eu pas mal de difficulté a comprendre le but de cette modif.
Je pense finalement avoir compris,aujourd'hui une Throwable une fois catcher ne peut etre throw sans etre dans la clause throws de la methode cette proposition le permettrait. On pourrait ainsi catcher ces throwable pour pouvoir faire un traitement et les "throwser" (dsl ) sans avoir a polluer la signature de la methode par throws Throwable qui n'a pas de signification precise.

mais imaginons ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
public maMethode(){
    try{
          ....
    }catch(final UneExceptionMetierException e){
        log("...");
        throw e;
    }
}

C'est possible ca ? si oui c'est pas terrible non ?

[n!co]

Je vote pour, mais avec la syntaxe d'adiGuba !

[gokud-o-matic]

super pour la proposition 7 ou d'adiguba.

Autant c'est bien beau d'avoir un langage qui évite les confusions, autant un peu de pragmatisme fait toute la différence dans le succès d'un langage. Voila pourquoi Ruby est maintenant dans le vent.

je suis désolé de contredire ceux qui dénonce un laxisme mais pondre inutilement 10 lignes pour logger une methode, autant dire que je me contente habituellement de catcher Exception et de perdre le type. c'est moins correct mais c'est plus facile a lire, et tous mes collègues approuvent. Pour tous mes projets, je n'ai pas besoin que mon code soit une œuvre d'art de génie logiciel si ca me fait perdre du temps.

du pragmatisme, que diable! nous ne sommes pas des machines.

[denisC]

Encore une fois, le problème ne se poserait pas avec la proposition 7, et ce serait beaucoup moins ambigü !!

Contre cette proposition. La proposition 7 adresse completement ce probleme, et est a mon sens beaucoup plus lisible et compréhensible.

[chtig]

Totalement contre également et totalement pour une solution style proposition 7, qui ne fait ni perdre en lisibilité ni en rigueur.