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

[bobuse]

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 ?

Je ne suis toujours pas sûr qu'on parle de la même chose.

Ici, il n'est pas question de permettre de jeter des exceptions qui ne sont pas déclarées dans le throws.
Il est bien question de permettre de déclarer dans le throws uniquement les exceptions pouvant être lancées par un throw, sachant que dans les types d'exceptions pris en compte sont bien ceux des méthodes englobées par le try et nom le type du catch.

Mais c'est vrai que l'exemple n'est pas très clair.
vbrabant, si tu pouvais nous éclairer un peu plus

[bulbo]

On parle de la même chose rassure toi.

Mais si tu regardes l'exemple, il y a un catch Throwable, qui, par définition catch tout.
Imaginons que dans un premier temps tu ai déclaré dans ton throws toutes les exceptions que tu sais possible et que plus tard tu rajoutes un appel qui lance une nouvelle exception et que tu l'oublie celle la..

Que va faire le catch ? Catcher tout comme l'utilisation de Throwable laisse a penser ou ne va-t'il catcher que les exceptions déclarées dans le throws ?

En fait je vois mal comment il pourrait savoir quoi catcher et il catchera tout (cas de try imbriqués: qui catch quoi ?) et donc rethrow de tout

Comment ne plus avoir de problème de compil dans ce cas, il y aura de toute façon problème, ou ira la nouvelle exception ? Qui la catchera ? Ou aura-t'on droit a une Runtime ?

Bref je ne veux pas de ce système, pourquoi ne pas faire des exceptions qu'on ne catch jamais et qui ne plante rien a la C++ tant qu'on y est ..

Bulbo

[bobuse]

Mais si tu regardes l'exemple, il y a un catch Throwable, qui, par définition catch tout.
Imaginons que dans un premier temps tu ai déclaré dans ton throws toutes les exceptions que tu sais possible et que plus tard tu rajoutes un appel qui lance une nouvelle exception et que tu l'oublie celle la..

Que va faire le catch ? Catcher tout comme l'utilisation de Throwable laisse a penser ou ne va-t'il catcher que les exceptions déclarées dans le throws ?

Le catch fera comme avant, il catchera tout ce qui hérite du type utilisé (ici Throwable, mais ça peut être autre chose). Par contre, le throws de la signature devra être modifiée pour ajouter ta nouvelle exception.

[bulbo]

Le catch fera comme avant, il catchera tout ce qui hérite du type utilisé (ici Throwable, mais ça peut être autre chose). Par contre, le throws de la signature devra être modifiée pour ajouter ta nouvelle exception.

Je ne vois pas très bien comment le compilo pourrait bien se débrouiller avec ça.. surtout en cas de try catch imbriqué qui lance quoi, qui doit déclarer quoi ..

Bref pas convaincu du tout par ce truc..

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.

[bulbo]

Tient une idée si throws ne plait pas: watch

Comment ça on risque de confondre avec catch

Bulbo

[xavlours]

Contre.

Je préfère la proposition 7 qui me semble être absolument équivalente (corrigez-moi si je me trompe) :

Code :

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

1
2
3
4
5
6
try {
  ...
} catch (IOException e | SQLException e) { // fault-il mettre des final ?
  log(...);
  throw e;
}