Discussion :

[_skip]

La seule chose que Java impose, c'est de déclarer les checked-exception que l'on remonte...
a++

T'avais peut être raison sur la stacktrace, j'ai peut être confondu c# et java lorsque j'ai dit qu'un throw ex; modifiait la stacktrace de ex. En c# c'est ce qui se produit, pour java pas le coeur de vérifier alors je te crois sur parole.
Mais le problème de fond reste toujours le même, si tu relances une exception de type "Exception" tu devras décorer toutes tes méthodes de throws Exception ce qui casse tout le concept.

[deltree]

-Tu peux tout à fait catcher exception du moment que tu fais une propagation en bonne et due forme et sans perte de l'information, java impose d'éviter ce genre de chose à cause des checked exceptions, mais dans d'autres langages c'est possible et tout à fait propre et sérieux.

Justement, je ne parles pas de ce qu'impose java, mais de ce que l'on s'impose à soi même pour garder un code propre donc maintenable.

-finally ça se déclenche aussi si tout s'est bien passé, c'est l'endroit idéal pour libérer des ressources mais pas pour effectuer un rollback.

Euh oui, là j'ai déconné à plein tube, finally c'est plutôt pour une fermeture de connection, de fichier...
il n'empêche que le cas du rollback est justement particulier: on doit le faire au plus haut niveau du service pour annuler toutes les opérations du service, ce qui rejoint mon cas de service de haut niveau.
Et du reste, on doit refaire un try catch dans le catch car on n'est pas sûr d'avoir toujours la connection si l'exception est justement une coupure de connection.

[adiGuba]

Mais le problème de fond reste toujours le même, si tu relances une exception de type "Exception" tu devras décorer toutes tes méthodes de throws Exception ce qui casse tout le concept.

Dans le cas des checked-exceptions seulement (ce qui n'existe pas en C#).

Si tu manipules des unchecked-exceptions (RuntimeException en Java) tu te retrouveras exactement dans le même cas qu'en C#.

Maintenant on pourrait faire un débat sur l'intérêt des checked-exception, mais c'est un autre sujet.

a++

[OWickerman]

Pour, mais avec une syntaxe bien pensée.

[nonpoluant]

C'est vrai que voir un separateur | comme ça, me fait plutot penser soit à du C pour separer des options du genre O_CREAT | O_RDWR soit à de l'OCaml pour separer des constructeurs ABR = Nil | Node of (int*ABR*ABR)
Mais pas habitué à ça en java pour ma part.

J'aimerais avoir une façon simple de catcher toutes les exceptions d'un coup sans avoir à faire une chaine à ralonge.

[adiGuba]

C'est vrai que voir un separateur | comme ça, me fait plutot penser soit à du C pour separer des options du genre O_CREAT | O_RDWR soit à de l'OCaml pour separer des constructeurs ABR = Nil | Node of (int*ABR*ABR)
Mais pas habitué à ça en java pour ma part.

Cela existe pourtant aussi en Java et la signification est très claire : "OU" !

J'aimerais avoir une façon simple de catcher toutes les exceptions d'un coup sans avoir à faire une chaine à ralonge.

Pour catcher toutes les exceptions on peut utiliser catch(Exception)... mais ce n'est pas très propre et peut poser d'autres problèmes (comme traiter des exceptions que l'on ne souhaiterais pas).


a++

[Dog Eata]

Pour, à condition de pouvoir spécifier le type de l'erreur attrapée :

Code :

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

1
2
3
4
5
6
7
try {
	// Tentative
}
catch (SQLException e : SQLWarning | BatchUpdateException) {
	// Echec
	e.getSQLState();
}

C'est plus précis que :

Code :

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

1
2
3
4
5
6
7
try {
	// Tentative
}
catch (SQLException e) {
	// Echec
	e.getSQLState();
}

car on attrape pas toutes les SQLException.
En même temps cela évite les lourdeurs du type :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
try {
	// Tentative
}
catch (SQLWarning e) {
	// Echec
	e.getSQLState();
}
catch (BatchUpdateException e) {
	// Echec
	e.getSQLState();
}

En cas d'omission du type de retour il pourrait être interprété comme étant simplement Exception. En effet, la plupart des exceptions usuelles ne comportent pas de méthodes en plus de celles déclarées dans Exception.

[fridobox]

Contre.
À mon avis,

• soit il y a une classe/interface mère pour les exceptions qu'on veut regrouper,
• soit les exceptions sont mal définies et cette classe/interface mère devrait exister.

Je suis de cet avis. Ce n'est pas peine de compliquer les choses. Si c'est vraiment le même traitement, il suffit de le mutualiser dans une méthode privée.

[*alexandre*]

pourquoi pas un

catch(Exception ...exs) {

}

[Uther]

Déjà posé plusieurs fois.
J'ai la flemme de la refaire en complet mais avec un catch sur Exception, on va catcher toutes les exceptions y compris les exceptions unchecked(null pointeur, division par 0, ...) qui normalement ne sont pas interceptées.

[deltree]

Selon les articles suivants, cette partie sera intégrée à Java 7 avec des | comme séparateurs:

http://tech.puredanger.com/2009/02/16/java7-update/
http://tech.puredanger.com/java7
https://jdk7.dev.java.net/
http://blogs.sun.com/theplanetarium/...ge_changes_for

ça pourrait faire l'objet d'un nouveau Thread unique pour tout java7, le débat sur les nouveautés java7 est obsolète?