2010-10-22 36 views
6

De temps en temps, je dois ajouter une nouvelle valeur à un type enum dans mon projet.Comment détecter une nouvelle valeur a été ajouté à une énumération et n'est pas géré dans un commutateur

public enum Day { 
    SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, 
    FILENOTFOUND //this one is new one 
} 

Ce que je voudrais est d'avoir une erreur de compilation pour chaque commutateur je qui ne traite pas la nouvelle valeur, comme celui-ci:

switch (color) { 
     case MONDAY: 
     case TUESDAY: 
     case WEDNESDAY: 
     case THURSDAY: 
        System.out.println("Mondays are bad."); 
        break; 

     case FRIDAY: System.out.println("Fridays are better."); 
        break; 

     case SATURDAY: 
     case SUNDAY: System.out.println("Weekends are best."); 
        break; 
    } 

Avoir un défaut: que lancers francs une exception n'est pas assez bonne, je voudrais que ce soit la compilation.

Je ne pense pas que ce soit possible, mais peut-être quelqu'un a une astuce ...

Je pensais que Findbugs aurait une règle pour trouver ceux mais je ne ai vu ceci: Eq: Covariant equals() method defined for enum (EQ_DONT_DEFINE_EQUALS_FOR_ENUM)

EDIT : Je choisis la réponse de Mark, j'utilise Eclipse et ça ressemble à ce dont j'avais besoin! Je ne suis pas un expert en findbugs du tout, donc j'ai peut-être manqué une telle fonctionnalité, bien que je ne le pense pas.

+0

ajouter un commentaire near enum declaration :-) –

+2

+1 pour ajouter FILENOTFOUND à un ensemble non apparenté de constantes d'enum –

+0

+0 pour ajouter FILENOTFOUND à un ensemble de constantes enum sans rapport. Pourquoi les gens trouvent-ils encore ça drôle? (Cela ne me dérange pas l'OP ou quelqu'un l'utilisant dans un exemple ad hoc, mais honnêtement, les gens pensent toujours que c'est drôle et upvote en conséquence, même après avoir vu cette référence comme 8000 fois?) –

Répondre

7

Eclipse possède un avertissement/une erreur au moment de la compilation que vous pouvez activer: La constante d'énumération n'est pas couverte par le "commutateur".

De vos propriétés du projet (ou les préférences générales), passez à compilateur Java ->Erreurs/avertissements, vérifiez les paramètres spécifiques Activer du projet. Vous trouverez l'avertissement sous Problèmes potentiels de programmation. Il est défini sur Ignorer par défaut, mais vous pouvez augmenter jusqu'à Avertissement ou Erreur. Je pensais que cela allait de soi, mais je suppose que je vais le dire quand même: cela ne s'applique que si vous développez dans Eclipse ou que vous l'utilisez pour la gestion de votre build. De toute évidence, un Findbugs ou équivalent équivalent serait la réponse "réelle" car il transcende l'EDI et peut être intégré dans le processus de construction.

+0

C'est une fonctionnalité intéressante, mais cela n'aidera pas les commutateurs existants sur l'énumération à laquelle vous ajoutez une nouvelle valeur. – rsp

+0

@rsp: Oui, c'est le cas. Si vous revenez en arrière et que vous modifiez l'énumération, en ajoutant une nouvelle valeur, il générera des avertissements/erreurs sur toutes les instructions switch qui utilisent cette énumération. –

+1

Cela me surprend qu'Eclipse ait cela alors que Findbugs ne le fait pas. –

2

Vous pouvez le faire en ajoutant une clause par défaut et l'exploitation forestière lorsqu'il est visité:

switch (color) { 
default: 
    log.error("Unknown color in switch: " + color); 
    break 

case MONDAY: /*FALLTHROUGH*/ 
case TUESDAY: 

(ajouter des commentaires fallthrough aider mainteneurs plus tard pour décider si vous avez oublié le code ou non :-))

Modifier Clarification copiée à partir des commentaires sur la réponse de Mark:

Une fonctionnalité IDE signalant des cas comme celui-ci est très bien pour le développeur au moment du changement, mais il n'atteint pas les changements i n autres parties du code dont votre code dépend.

Il ne rend pas le code cient contenant des commutateurs sur enums robuste contre les modifications sauf si elles sont recompilées avec la nouvelle version.

Cela aide lorsque le code client enregistre des cas non gérés; Le code déployé n'a pas toujours un contrôle total sur son chemin de classe ou sur les versions des bibliothèques qu'il contient.

+2

Ceci est une vérification à la compilation comme demandé par le PO? –

+0

Pas de compilation si limitée dans l'utilisation et inapplicable à la question. Edit: enlevé d/v, c'est toujours utile, donc je ne peux pas l'appeler "faux". –

+1

@Kirk Woll, non ce n'est pas. L'utilisation de ce modèle rend votre code plus robuste par rapport aux modifications apportées aux classes/énumérations utilisées même si vous ne recompilez pas le code contenant le commutateur. Comme je le vois c'est une meilleure alternative pour s'assurer que vous ne manquez pas ce genre de situation, même si votre IDE supporte ce type de vérification. – rsp

0

IntelliJ était un contrôle où tous les cas n'étaient pas définis. Il a une auto-correction pour remplir les cas manquants.