Il modo migliore per definire codici / stringhe di errore in Java?

Sto scrivendo un servizio web in Java e sto cercando di capire il modo migliore per definire i codici di errore e le stringhe di errore associate . Devo avere un codice di errore numerico e una stringa di errore raggruppati insieme. Sia il codice di errore che la stringa di errore verranno inviati al client che accede al servizio web. Ad esempio, quando si verifica una SQLException, potrei voler fare quanto segue:

// Example: errorCode = 1, 
//          errorString = "There was a problem accessing the database."
throw new SomeWebServiceException(errorCode, errorString);

Al programma client potrebbe essere visualizzato il messaggio:

"Si è verificato l'errore n. 1: si è verificato un problema durante l'accesso al database."

Il mio primo pensiero è stato quello di utilizzare uno Enumdei codici di errore e sovrascrivere i toStringmetodi per restituire le stringhe di errore. Ecco cosa mi è venuto in mente:

public enum Errors {
  DATABASE {
    @Override
    public String toString() {
      return "A database error has occured.";
    }
  },

  DUPLICATE_USER {
    @Override
    public String toString() {
      return "This user already exists.";
    }
  },

  // more errors follow
}

La mia domanda è: c'è un modo migliore per farlo? Preferirei una soluzione in codice, piuttosto che leggere da un file esterno. Sto usando Javadoc per questo progetto e sarebbe utile documentare i codici di errore in linea e aggiornarli automaticamente nella documentazione.

Bene, c'è sicuramente un'implementazione migliore della soluzione enum (che in genere è abbastanza carina):

public enum Error {
  DATABASE(0, "A database error has occured."),
  DUPLICATE_USER(1, "This user already exists.");

  private final int code;
  private final String description;

  private Error(int code, String description) {
    this.code = code;
    this.description = description;
  }

  public String getDescription() {
     return description;
  }

  public int getCode() {
     return code;
  }

  @Override
  public String toString() {
    return code + ": " + description;
  }
}

Potresti voler sovrascrivere toString () per restituire solo la descrizione, non sono sicuro. Ad ogni modo, il punto principale è che non è necessario eseguire l'override separatamente per ogni codice di errore. Si noti inoltre che ho specificato esplicitamente il codice invece di utilizzare il valore ordinale: ciò semplifica la modifica dell'ordine e l'aggiunta / rimozione di errori in un secondo momento.

Non dimenticare che questo non è affatto internazionalizzato, ma a meno che il tuo client del servizio web non ti invii una descrizione locale, non puoi comunque internazionalizzarlo facilmente da solo. Almeno avranno il codice di errore da usare per i18n sul lato client ...

Per quanto mi riguarda, preferisco esternalizzare i messaggi di errore in un file delle proprietà. Questo sarà davvero utile in caso di internazionalizzazione della tua applicazione (un file delle proprietà per lingua). È anche più facile modificare un messaggio di errore e non sarà necessaria alcuna ricompilazione dei sorgenti Java.

Sui miei progetti, generalmente ho un'interfaccia che contiene codici di errore (String o integer, non interessa molto), che contiene la chiave nei file delle proprietà per questo errore:

public interface ErrorCodes {
    String DATABASE_ERROR = "DATABASE_ERROR";
    String DUPLICATE_USER = "DUPLICATE_USER";
    ...
}

nel file delle proprietà:

DATABASE_ERROR=An error occurred in the database.
DUPLICATE_USER=The user already exists.
...

Un altro problema con la tua soluzione è la manutenibilità: hai solo 2 errori e già 12 righe di codice. Quindi immagina il tuo file di enumerazione quando avrai centinaia di errori da gestire!

Il sovraccarico di toString () sembra un po 'icky - che sembra un po' un allungamento del normale utilizzo di toString ().

Che dire:

public enum Errors {
  DATABASE(1, "A database error has occured."),
  DUPLICATE_USER(5007, "This user already exists.");
  //... add more cases here ...

  private final int id;
  private final String message;

  Errors(int id, String message) {
     this.id = id;
     this.message = message;
  }

  public int getId() { return id; }
  public String getMessage() { return message; }
}

mi sembra molto più pulito ... e meno prolisso.

Al mio ultimo lavoro sono andato un po 'più a fondo nella versione enum:

public enum Messages {
    @Error
    @Text("You can''t put a {0} in a {1}")
    XYZ00001_CONTAINMENT_NOT_ALLOWED,
    ...
}

@Error, @Info, @Warning vengono conservati nel file di classe e sono disponibili in fase di esecuzione. (Avevamo anche un paio di altre annotazioni per aiutare a descrivere la consegna dei messaggi)

@Text è un'annotazione in fase di compilazione.

Ho scritto un processore di annotazioni per questo che ha fatto quanto segue:

• Verificare che non ci siano numeri di messaggio duplicati (la parte prima del primo trattino basso)
• Controlla la sintassi del testo del messaggio
• Genera un file messages.properties che contiene il testo, codificato dal valore enum.

Ho scritto alcune routine di utilità che hanno aiutato a registrare gli errori, includerli come eccezioni (se lo si desidera) e così via.

Sto cercando di convincerli a lasciarmi open-source ... - Scott

Ti consiglio di dare un'occhiata a java.util.ResourceBundle. Dovresti preoccuparti di I18N, ma ne vale la pena anche se non lo fai. L'esternalizzazione dei messaggi è un'ottima idea. Ho scoperto che era utile poter fornire un foglio di calcolo agli uomini d'affari che permettesse loro di inserire nella lingua esatta che volevano vedere. Abbiamo scritto un'attività Ant per generare i file .properties in fase di compilazione. Rende I18N banale.

Se stai usando anche la primavera, tanto meglio. La loro classe MessageSource è utile per questo genere di cose.

Solo per continuare a frustare questo particolare cavallo morto, abbiamo fatto buon uso di codici di errore numerici quando gli errori vengono mostrati ai clienti finali, poiché spesso dimenticano o interpretano erroneamente il messaggio di errore effettivo, ma a volte possono conservare e segnalare un valore numerico che può fornire hai un indizio di ciò che è realmente accaduto.

Ci sono molti modi per risolvere questo problema. Il mio approccio preferito è avere interfacce:

public interface ICode {
     /*your preferred code type here, can be int or string or whatever*/ id();
}

public interface IMessage {
    ICode code();
}

Ora puoi definire un numero qualsiasi di enumerazioni che forniscono messaggi:

public enum DatabaseMessage implements IMessage {
     CONNECTION_FAILURE(DatabaseCode.CONNECTION_FAILURE, ...);
}

Ora hai diverse opzioni per trasformarle in stringhe. È possibile compilare le stringhe nel codice (utilizzando annotazioni o parametri del costruttore enum) oppure leggerle da un file di configurazione / proprietà o da una tabella di database o da una combinazione. Quest'ultimo è il mio approccio preferito perché avrai sempre bisogno di alcuni messaggi che puoi trasformare in testo molto presto (cioè mentre ti connetti al database o leggi la configurazione).

Sto usando unit test e framework di riflessione per trovare tutti i tipi che implementano le mie interfacce per assicurarmi che ogni codice venga utilizzato da qualche parte e che i file di configurazione contengano tutti i messaggi previsti, ecc.

Utilizzando framework in grado di analizzare Java come https://github.com/javaparser/javaparser o quello di Eclipse , puoi persino controllare dove vengono utilizzate le enumerazioni e trovare quelle inutilizzate.

Io (e il resto del nostro team nella mia azienda) preferiamo sollevare eccezioni invece di restituire codici di errore. I codici di errore devono essere controllati ovunque, passati in giro e tendono a rendere il codice illeggibile quando la quantità di codice diventa maggiore.

La classe di errore definirà quindi il messaggio.

PS: e in realtà tengo anche all'internazionalizzazione!
PPS: potresti anche ridefinire il metodo di rilancio e aggiungere logging, filtri ecc. Se necessario (almeno negli ambienti, dove le classi di eccezione e gli amici sono estendibili / modificabili)

Un po 'tardi ma stavo solo cercando una bella soluzione per me stesso. Se si dispone di un diverso tipo di messaggio di errore, è possibile aggiungere una semplice fabbrica di messaggi personalizzata in modo da poter specificare più dettagli e formato che si desidera in seguito.

public enum Error {
    DATABASE(0, "A database error has occured. "), 
    DUPLICATE_USER(1, "User already exists. ");
    ....
    private String description = "";
    public Error changeDescription(String description) {
        this.description = description;
        return this;
    }
    ....
}

Error genericError = Error.DATABASE;
Error specific = Error.DUPLICATE_USER.changeDescription("(Call Admin)");

EDIT: ok, usare l'enum qui è un po 'pericoloso poiché si modifica in modo permanente l'enum particolare. Immagino che sarebbe meglio passare alla classe e usare campi statici, ma non puoi più usare '=='. Quindi immagino che sia un buon esempio di cosa non fare (o farlo solo durante l'inizializzazione) :)

enum per il codice di errore / la definizione del messaggio è ancora una buona soluzione sebbene abbia problemi i18n. In realtà possiamo avere due situazioni: il codice / messaggio viene visualizzato all'utente finale o all'integratore di sistema. Per l'ultimo caso, I18N non è necessario. Penso che i servizi web siano molto probabilmente il caso successivo.

L'utilizzo interfacecome costante del messaggio è generalmente una cattiva idea. Perderà permanentemente nel programma client come parte dell'API esportata. Chissà, che i programmatori client successivi potrebbero analizzare quei messaggi di errore (pubblici) come parte del loro programma.

Sarai bloccato per sempre per supportare questo, poiché le modifiche al formato della stringa potrebbero / potrebbero interrompere il programma client.

Si prega di seguire l'esempio seguente:

public enum ErrorCodes {
NO_File("No file found. "),
private ErrorCodes(String value) { 
    this.errordesc = value; 
    }
private String errordesc = ""; 
public String errordesc() {
    return errordesc;
}
public void setValue(String errordesc) {
    this.errordesc = errordesc;
}

};

Nel tuo codice chiamalo come:

fileResponse.setErrorCode(ErrorCodes.NO_FILE.errordesc());

Utilizzo PropertyResourceBundle per definire i codici di errore in un'applicazione aziendale per gestire le risorse del codice di errore locale. Questo è il modo migliore per gestire i codici di errore invece di scrivere codice (può essere valido per pochi codici di errore) quando il numero di codici di errore è enorme e strutturato.

Guarda il documento java per ulteriori informazioni su PropertyResourceBundle