2015-07-15 14 views
7

Mi piace creare classi Exception i cui nomi indicano i problemi specifici dell'applicazione che vengono notati e generati.Come evitare la ripetizione all'interno delle classi di eccezioni java personalizzate

Per definirli, in genere viene definito un nuovo class la cui super classe è del tipo Exception.

A causa delle molteplici costruttori comuni nella classe genitore Exception, in genere la sottoclasse sembra qualcosa di simile:

package com.example.exception; 

/** 
* MyException is thrown when some application-level expectation is not met. 
*/ 
public class MyException extends Exception { 

    public MyException() { 
     super(); 
    } 

    public MyException(String message) { 
     super(message); 
    } 

    public MyException(Throwable cause) { 
     super(cause); 
    } 

    public MyException(String message, Throwable cause) { 
     super(message, cause); 
    } 

} 

Guardando a questo dal punto di vista DRY, trovo questo approccio noioso, particolare quando sono definite le gerarchie Exception.

Conosco strumenti come Lombok che aiutano a ridurre la ripetizione per i modelli Java comuni; ci sono suggerimenti per strumenti che affrontano questo specifico problema di ripetizione per le classi di eccezioni?

+2

Questo mi sembra buono. –

+0

@SotiriosDelimanolis Credo che il punto che l'OP sta cercando di fare è che se ha 10 classi di eccezioni personalizzate, deve ripetere questo codice in tutte quelle classi di eccezioni. – CKing

+2

@CKing No, ho capito. Sarebbe bene con me. –

risposta

4

Se si creano eccezioni "aziendali", non è necessario copiare tutti i costruttori da Exception. Invece, crea eccezioni che usano i tuoi oggetti di business. Ad esempio, se una richiesta non riuscita, che è modellato da un oggetto business Request si potrebbe creare una RequestFailedException con un unico costruttore:

public RequestFailedException(Request request) { 
    super("Request to " + request.getUrl() + " failed."; 
} 

Si potrebbe anche memorizzare un riferimento all'oggetto Request in un campo e fornire un getter così che il metodo che gestisce l'eccezione possa ottenere maggiori informazioni su ciò che stava accadendo.

+1

Sono d'accordo che per certe 'Eccezioni', incapsulare informazioni rilevanti è una buona idea, ma non tutti gli Eccezioni hanno quel requisito; non sono la maggior parte dei 'wrapper con nome personalizzato' Exception? Trovo semplicemente fastidioso che per quel tipo di 'Exception's, tutto questo codice duplicato sia stato creato. –

+1

Penso che noi (gli sviluppatori Java) tendiamo a lanciare eccezioni troppo spesso. Ad esempio, provare ad offrire metodi per verificare alcune condizioni in anticipo invece di implementare un metodo, che genera un'eccezione se la condizione non viene soddisfatta. Inoltre, se qualcosa va storto, cerca di essere resiliente e restituire qualcosa che potrebbe non essere perfetto ma comunque utile per il chiamante. – hzpz

+1

Mentre concordo pienamente su ciò che questa risposta dice, non è ciò che l'OP ha chiesto. –

Problemi correlati