Discussion :

[Jack Sparrow]

@LittleBean

Pour cet exemple précis, la deuxième méthode ne m'a pas l'air adéquate car :

- la méthode retrait peut être considerée comme une opération atomique qui gère déjà tous les cas d'erreurs
- la méthode retrait peut toujours péter via une exception -> Il y a 2 fois le même traitement d'erreur qui va se retrouver quelque part.
Puisqu'évidemment, la ligne "if (compteEnBanque.getSolde() > demandeRetrait)" ne garantie pas du tout que l'on puisse effectuer le retrait". Donc que l'exception de dépassement ne sera pas levé

[hibour]

C'est vrai que j'ai un peu trop simplifié mon exemple, mais on pourrait garder toutes les infos (sauf la stacktrace).

Je trouve ta solution pas mal, à condition d'avoir un message d'erreur bien précis qui détaille le nom de la méthode et le pourquoi de l'erreur particulièrement si on se trouve dans un boucle

[tchize_]

Oui mais là on est en plein dans l'anti-pattern : à quoi peut bien servir une exception qui ne contiendrait aucune info sur l'erreur !?

a++

Je répondrais pas une classe de l'api java qui le fait

java.lang.OutOfMemoryError

[adiGuba]

Je répondrais pas une classe de l'api java qui le fait

java.lang.OutOfMemoryError

OutOfMemoryError génère bien un stacktrace

a++

[tchize_]

t'es sur? alors c'est la manière don la jvm le déclenche qui empeche le stacktrace, je les ai toujours vu sans stacktrace, et pour cause, pas assez de mémoire que pour créer le stacktrace.

[adiGuba]

t'es sur? alors c'est la manière don la jvm le déclenche qui empeche le stacktrace, je les ai toujours vu sans stacktrace, et pour cause, pas assez de mémoire que pour créer le stacktrace.

Tu me mets le doute et j'ai vérifié j'ai bien un stacktrace, mais apparemment ce n'était pas le cas avant Java 5u12 : http://bugs.sun.com/bugdatabase/view...bug_id=4753347

a++

[tchize_]

effectivment, mes Out of memory error arrivent souvent en prod, et on est à un jvm < à cette révision (et en plus en saveur HP-UX, la blague!)

Merci d'avoir déterré çà