Parce que dans les instructions du case value1 et value2 il y a un

 if(erreur)
   return false;
 

Ou rien de ce genre ?

Ok, il aurait pu mettre break à la place et un return true après... mais sinon, je vois pas le problème, si les instructions sont différentes d'un case à un autre

Pas forcement étonnant si c'est un gestionnaire d'évènement et qu'on veut indiquer qu'on a bien reçu l'évènement et qu'il n'est pas nécessaire de le propager.

Si les valeurs autres que value1 et value2 ne doivent pas faire de traitement particulier, ce n'est pas pour autant qu'elles doivent retourner une erreur (ou assimilé).
Et si les traitements peuvent faire des return false, ou si la personne prévoit que plus tard il y aura des valeurs pouvant retourner false, le code n'est pas réellement choquant.

En fait, la seule chose qui me choque vraiment, c'est d'avoir plusieurs return dans le switch, pour ma part je mettrais la valeur dans une variable qui serait retournée après le switch.

Ou alors une Exception est lancée.

Si ce code est donné dans un cours, le prof n'explique pas le pourquoi du comment?

Je n'ai rien précisé car ça me semblait évident que tel que c'est raconté, les instructions étaient neutres, sinon ça n'aurait aucun sens. Notamment en disant explicitement "c'est pour toujours retourner « true »".
Il n'y avait aucun return false.
Le problème est qu'en programmation quand une instruction doit être répétée à chaque fois, on la généralise, pour moi, c'est une règle vraiment basique, pas grave mais basique, et ici le "return true" aurait du être à la fin. Sans compter que le SWITCH était à la limite de servir à rien... il ne sert que 2 conditions.


Faut vraiment que je revois ma façon de raconter (Et pourtant, je trouve qu'il y en a des vraiment plus mal racontés qui passent mieux). Et je crois qu'il y en a un ou deux autres sur Android que j'ai eu du mal à raconter... ça promet. :D

Ce n'est effectivement pas très "propre" mais personnellement il n'y a rien ici qui me choque outre mesure. Par contre comme l'a dit CrazyCat j'aurais déclaré un boolean ret = true; en début de fonction que j'aurais renvoyé après le switch...

Si les instructions sont vraiment neutres, ce qui réglerais le problème est d'en faire une méthode qui renvoie void. Après, de la à en faire un pebkac...

J'avoue coder dans un style très K&R, et la multiplicité des return ne me choque pas. J'ai limite tendance à trouver que ça rend le code plus lisible en indiquant de manière quasiment explicite les fins de traitement.

Après, autant je fais confiance à Ritchie & Kernignan en C, autant je n'ai pas la moindre idée de ce que ça fait en Java.

Pas forcément... La méthode est peut-être déclarée dans une classe mère, retourne false par défaut. Ici, la surcharge retourne true pour dire qu'elle a traité le message. Bon, par contre, une annotation @Override aurait été mieux si c'était le cas.

Je ne suis absolument pas choqué par ce code, si ce n'est qu'il n'est pas très esthétique.

Je vois. Ce n'est pas dramatique (j'ai vu pire T_T) mais en effet son code n'est pas très élégant...

AVANT le switch pour ma part ...

*Kernighan

Je pensais aussi à cela, mais ça ne justifie pas ce contexte (certes limité) : un type de retour void ferait aussi bien l'affaire, le test de réussite se faisant sur la levée ou non d'une Exception.
Après on peut considérer que la méthode puisse être extensible et plus tard renvoyer false afin d'indiquer un autre niveau d' "erreur".

Si tu fais un return avant le switch je ne vois pas bien comment tu vas pouvoir l'exécuter...

Ça ne set pas à grand chose de la mutualiser le code pour une seule ligne qui se répète.
Et mettre le return immédiatement quand on a fini le traitement, et non pas 50 lignes plus loin, rend le code plus lisible.

Pour une fonction de quelques lignes j'aurai mis un seul return à la fin, mais il n'y a rien qui me choque ici, à part peut-être le default vide, mais il y a des normes de programmation qui imposent d'avoir systématiquement un default.

Et avoir une fonction qui retourne systématiquement true ne me choque pas non plus: ça permet de standardiser les appels (toutes les fonctions retournent un booléen) et de faire facilement évoluer le code si on prévoit de rajouter un cas "false".

Cette méthode devait retourner un résultat, du fait d'Android si je me souviens bien, qu'elle retourne tout le temps true n'est pas un problème, c'est fréquent pour ce genre de méthode type callback/event listener.

On peut aussi implémenter une interface dont le contrat indique que la méthode doit renvoyer true en cas de succès, même si c'est toujours le cas dans ton implémentation.

Je pense qu'il veut dire « déclarer le booléen avant le switch ».

Haa non non, je voulais bien dire le return avant le switch ... vu qu'il ne fait rien d'intéressant ce switch, autant faire un return true avant, ça ira plus vite.

A moins naturellement qu'une partie du code ait été supprimé et remplacé par "// Instructions" et "//Autres instructions" ...

Si le code montré est l'original le switch ne sert à rien.