J'apprends simplement sur les énumérations en Java. Lorsque j'exécute le code ci-dessous, je reçois une erreur que je reproduit également ci-dessous. Fondamentalement, ma question est la suivante: lorsque je définis une méthode dans une énorme, et dans cette méthode, je veux vérifier la valeur de l'énum de sorte que je puisse faire quelque chose en fonction de cette valeur, comment puis-je exécuter ce chèque?
Ci-dessous, j'ai une énumération avec trois valeurs possibles et dans la méthode I Obtenir l'erreur P> getNext code>, j'ai trois déclarations de comparaison de la valeur de cette énumée avec chacune des trois valeurs possibles. Mais je reçois toujours une erreur disant qu'il y a un chemin sans retour.
$ javac enumerations/TrafficLightDemo2.java
enumerations/TrafficLightDemo2.java:26: error: missing return statement
}
^
1 error
3 Réponses :
TrafficLightColor2 getNext() { if (this.equals(TrafficLightColor2.GREEN)) { return TrafficLightColor2.YELLOW; } if (this.equals(TrafficLightColor2.YELLOW)) { return TrafficLightColor2.RED; } if (this.equals(TrafficLightColor2.RED)) { return TrafficLightColor2.GREEN; } } This method doesn't return the value if all 3 if are false.Add return at the and or better throw an error, e.g.throw new IllegalArgumentException("Unsupported enum")
Oui, l'erreur est claire. Cependant, je suis à l'intérieur d'une méthode d'instance d'énumération. L'énumération ne peut avoir qu'une des trois valeurs et j'ai testé pour chacune des trois valeurs possibles de GetNext (). Pourquoi le compilateur n'est-il pas capable de comprendre que si l'énumération existe (qu'elle fait depuis que je suis à l'intérieur de sa méthode), elle tombera nécessairement dans l'un des trois cas?
Vous avez déclaré que votre méthode doit renvoyer TrafficLightColor2, définissant l'exception dans l'affaire par défaut, vous précisez que vous savez que tous les cas sont couverts. Le compilateur n'est pas si intelligent de comprendre que vous avez couvert chaque cas. C'est une analyse statique qui dit qu'il y a des flux découverts.
Avez-vous envisagé d'inclure l'état suivant avec les valeurs déclarées?
TrafficLightColor2 trafficLightColor = TrafficLightColor2.GREEN; System.out.println(TrafficLightColor2.valueOf(trafficLightColor.getNextState()));
L'avantage d'utiliser des champs d'instance dans les classes ENUM est que vous pouvez associer facilement des détails de mise en œuvre avec vos constantes indépendantes de votre API. En d'autres termes, vous pouvez facilement associer des données avec vos constantes ENUM qui admettraient une solution élégante que vous ne vous êtes pas marié à jamais dans le cas où, par exemple, vous devez ajouter une nouvelle constante d'énum.
Alors, vous Peut généreusement simplifier votre implémentation tout en remplissant le même contrat comme suit: p> Cette version présente des avantages à votre implémentation initiale: il est plus facile de gérer depuis, si les constantes d'enum sont ajoutées. , le compilateur vous obligera à ajouter une valeur de commande. Dans l'original, si vous avez oublié de modifier votre bloc IF-else après avoir ajouté une constante, votre programme continuerait à fonctionner, mais cela ne fournirait pas le comportement correct. Et parce que la mise en œuvre de la commande code> est masquée, vous êtes libre de le supprimer ou de le modifier à une autre implémentation à tout moment sans affecter l'exactitude de votre API. P> P>
Oui, c'est une belle version. Cependant, ce que je veux vraiment savoir, c'est pourquoi l'erreur existait en premier lieu, étant donné que je représentais toutes les constantes de dénombrement possibles dans mes déclarations si elles. Une déclaration de retour n'est-elle pas une déclaration de retour après les trois déclarations pour être un code non accessible en pratique? Ou n'est-ce pas un code inaccessible?
Le compilateur n'est pas suffisamment intelligent de savoir que vous avez testé toutes les conditions possibles dans vos déclarations si. Il suppose que la dernière déclaration si elle pourrait être évaluée à la fausse. Dans le cas où il l'a fait, l'exécution dans la méthode atteindrait le support final sans rencontrer une déclaration de retour (qui est requise). Vous pouvez réparer votre méthode car elle se tient en lançant une exception avant le support final. Ceci est habituellement Jetez New AssertionError ("inaccessible"); code>.
Votre
si code> a échoué, et il n'y a pas de
retour code> disponible dans ce cas. Après votre
rouge code> condition, renvoyez
ceci code> ou un état par défaut
De plus, dans votre énum, vous n'avez pas besoin d'avoir Traqueflighcolor2 sur vos états (c'est-à-dire
.Qui.equals (vert) code> au lieu de
this.equals (trapplighcolor2.green) code>) code>)
Je reçois cette logique du message d'erreur, mais n'est-ce pas si les déclarations de si couvrent tous les cas possibles? La méthode GetNext () est à l'intérieur d'une énumération et l'énumération ne peut être que l'une des trois constantes de dénombrement, chacune étant testée dans un si. En théorie, je manque d'une certaine manière que tous les ifs échoueraient?
Vous pouvez surestimer ce que les déclarations
si code> peuvent faire, ils exécutent leur bloc de code, soit ils ne font pas partie de la structure de classe ou d'objet qu'ils pourraient être. Un pari plus sûr serait de définir Une initiale
retourvalue code> à certaines paramètres par défaut, avez votre
si code> inscrit affectation à
retourvalue code> puis revenir à la fin de cette méthode.
Vous avez raison dans lesquels les énormes ont des plages / valeurs limitées, mais le code sage, il n'est pas possible car toutes les méthodes non annulées doivent renvoyer quelque chose dans toutes les situations, même si la logique indique que cela ne devrait jamais arriver. "En théorie" ne devrait s'appliquer que si votre code est également "sonore", dans ce cas ce que vous voyez est attendu.