2010-10-22 6 views
6

Di tanto in tanto devo aggiungere un nuovo valore a un tipo enum nel mio progetto.Come rilevare un nuovo valore è stato aggiunto a un enum e non viene gestito in uno switch

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

Quello che vorrei è avere un errore di tempo compilazione per ogni interruttore che ho, che non sta trattando il nuovo valore, come questo:

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; 
    } 

Avere un default: che getta qualche eccezione non è abbastanza buona, mi piacerebbe che fosse tempo di compilazione.

Non credo che questo è possibile, ma forse qualcuno ha un trucchetto ...

ho pensato Findbugs avrebbe una regola per trovare quelli, ma ho visto solo questo: Eq: Covariant equals() method defined for enum (EQ_DONT_DEFINE_EQUALS_FOR_ENUM)

EDIT : Scelgo la risposta di Mark, io uso Eclipse e sembra proprio quello di cui avevo bisogno! Non sono affatto un esperto di findbugs quindi potrei aver perso tale funzionalità, anche se non la penso così.

+0

aggiungi commento vicino alla dichiarazione enum :-) –

+2

+1 per aggiungere FILENOTFOUND a un insieme non correlato di costanti enum –

+0

+0 per aggiungere FILENOTFOUND a un insieme non correlato di costanti enum. Perché la gente lo trova ancora divertente? (Non mi interessa l'OP o qualcuno che lo usa in un esempio ad hoc, ma onestamente la gente pensa ancora che questo sia divertente e di conseguenza upvote, anche dopo aver visto questo riferimento come 8000 volte?) –

risposta

7

Eclipse ha un avviso/errore in fase di compilazione che è possibile abilitare: Costante enum non coperta su "interruttore".

Dalla proprietà del progetto (o preferenze generali), vai a Java Compiler ->errori/avvisi, controllare attivare le impostazioni specifiche di progetto. Troverai l'avviso sotto Potenziali problemi di programmazione. È impostato su Ignora per impostazione predefinita ma è possibile eseguirlo fino a Avviso o Errore.

Modifica: Ho pensato che questo è ovvio, ma suppongo che lo dirò comunque: questo è applicabile solo se si sta sviluppando in Eclipse o si utilizza per la gestione della build. Ovviamente un Findbug o un equivalente simile sarebbe la risposta "reale" poiché trascende l'IDE e può essere integrato nel processo di costruzione.

+0

Questa è una bella funzionalità, ma non sarà di aiuto sugli switch esistenti sull'enum a cui stai aggiungendo un nuovo valore. – rsp

+0

@ rsp: Sì, sì. Se torni indietro e modifichi l'enumerazione, aggiungendo un nuovo valore, genererà avvisi/errori su tutte le istruzioni switch che utilizzano quell'enumerazione. –

+1

Mi sorprende che Eclipse abbia questo mentre Findbugs no. –

2

Si potrebbe fare che con l'aggiunta di una clausola e la registrazione di default quando viene visitato:

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

case MONDAY: /*FALLTHROUGH*/ 
case TUESDAY: 

(aggiunta di commenti falltrough aiutano manutentori successive per decidere se si è dimenticato il codice o no :-))

Modifica Chiarimento copiato dai commenti sulla risposta di Mark:

Un caso di segnalazione di caratteristiche IDE come questo va bene per lo sviluppatore al momento della modifica ma non rileva i cambiamenti n altre parti di codice da cui dipende il tuo codice.

Non rende il codice cient contenente gli switch su enumerazione robusta rispetto alle modifiche, a meno che non vengano ricompilati con la nuova versione.

Aiuta quando il codice client registra casi non gestiti; il codice distribuito non ha sempre il pieno controllo sul suo classpath o sulle versioni delle librerie su di esso.

+2

questo è un controllo in fase di compilazione come richiesto dall'OP? –

+0

Non in fase di compilazione, così limitato nell'uso e inapplicabile alla domanda. Modifica: rimosso d/v, questo è ancora utile quindi non posso chiamarlo "sbagliato". –

+1

@ Kirk Woll, no non lo è. L'utilizzo di questo modello rende il codice più robusto rispetto alle modifiche alle classi/enumerazioni utilizzate anche se non si ricompila il codice contenente lo switch. Come vedo, è un'alternativa migliore per assicurarti di non perdere questo tipo di situazione, anche se il tuo IDE supporta questo tipo di controllo. – rsp

0

IntelliJ era un controllo in cui non tutti i casi sono stati impostati. Ha una correzione automatica per riempire i casi mancanti.

Problemi correlati