Come convalidare i messaggi di eccezione? [chiuso]

-1

Il mio superiore mi ha chiesto di convalidare ogni singolo campo di input nel progetto che include i messaggi di eccezione. Quindi, ho ragione a usare Exceptional Handler per validare il messaggio Exception.

ExceptionalHandler

 public class ExceptionHandler {
        public void handle(String s){
        if(s!=null) {
            throw new DBException(s);
        }
        throw new DBException("received null message");
        }
    }

DBException

public class DBException extends RuntimeException {
    public DBException(String s) {
        super(s);
    }
}

E sto chiamando handle da DBService con qualcosa di simile

.
dh.handle(fileName+" Not Found.");
.

Quindi voglio sapere come convalidare i messaggi di eccezione e c'è anche qualche metodo specifico per chiamare le eccezioni di runtime personalizzate?

    
posta RajeeV VenkaT 27.04.2016 - 12:41
fonte

2 risposte

1

La convalida sta facendo in modo che qualcosa si trovi nello stato che ci si aspetta che sia.

Ad esempio, l'utente inserisce "a Date".

Ovviamente, gli utenti non possono effettivamente inserire "una data"; possono solo inserire la rappresentazione del carattere di "una data", in un formato "definito" definito dalla loro posizione nazionale / geografica e / o preferenza personale (sì, gli utenti possono modificare il proprio formato data. !).
Il tuo codice deve convertire quel valore [String] in un valore Data ma, prima che tu possa farlo, dovresti controllare che il valore inserito possa essere convertito da un formato a l'altro.

Se non è nel formato che ti aspetti, potresti scegliere di lanciare un'eccezione.

Perché dovresti farlo? La risposta è non per mostrare un messaggio di errore all'utente. Questa è una tattica di "ultima istanza" e potrebbero esserci molti modi migliori per affrontare il problema causato dalla tipizzazione dubbia dell'utente. Ad esempio, potresti semplicemente scegliere di cambiare il colore di sfondo del campo in qualcosa di lurido; in questo modo l'utente può vedere che c'è un problema e risolverlo, ma non vuoi che il tuo metodo di classe di servizio "raggiunga" il codice dell'interfaccia utente e chiacchiera con i colori. In questo caso, potresti lanciare un'eccezione specifica che descrive un campo [ny] che contiene un valore non valido. Se vuoi ottenere veramente specifico, potresti avere un'eccezione per ogni campo; probabilmente eccessivo.

Il codice dell'interfaccia utente cattura quindi questa eccezione e la "gestisce", modificando il colore del campo pertinente.

Dove getti l'eccezione? Nel punto in cui il tuo codice decide "Non posso andare oltre senza rompere".

Dove cattura l'eccezione? Nel punto in cui il tuo codice può fare qualcosa di utile con esso. In questo caso, è necessario ricolorare un campo. In alcuni casi, lo scrivi su un file (per intero) e poi mostra all'utente un messaggio "più amichevole". Come ultima risorsa, potresti non prenderlo affatto e lasciare che l'intero programma si blocchi e bruci (in questo caso, il Run-Time cattura l'eccezione).

Inoltre (ed è qui che le eccezioni diventano "interessanti") potresti essere in grado di intraprendere qualche azione correttiva che consentirebbe al tuo codice originale di continuare come se l'eccezione non fosse mai avvenuta . In questo caso, potresti avere un codice all'interno del tuo metodo che cattura l'eccezione "Data non valida" e, invece, sostituisce il valore errante con, ad esempio, la data odierna. OK, questo è eccessivo e una semplice istruzione "if" potrebbe essere sufficiente ma, si spera, puoi vedere l'effetto netto - lasciare che il codice funzioni normalmente; individuare se accade qualcosa di "eccezionale", gestirlo e poi continuare).

Nota: è "eccezionale", non "inaspettato".
Hai pensato a cosa potrebbe accadere e inserire il codice per gestire quell'eventualità, nella strana occasione in cui ciò potrebbe accadere.

    
risposta data 27.04.2016 - 13:23
fonte
1

Certo, puoi avere un parser per analizzare il messaggio di un'eccezione, passare questo messaggio alla classe ExceptionHandler e fare qualche logica su di esso.

Ma sarebbe ancora meglio ripensare il tuo design. Molto probabilmente sei costretto a gestire il messaggio perché la tua albero delle eccezioni è progettata in modo errato.

Vuoi che le classi di eccezioni rappresentino gli stati eccezionali, non i messaggi di eccezione al loro interno.

In questo modo, rilevando specifici tipi di eccezione (come DatabaseConnectionException o DatabaseQueryException invece di un generale DatabaseException ) sai già cosa è andato storto senza dover controllare il messaggio.

Il messaggio può fornire dati aggiuntivi, ma non dovrebbe essere usato come mezzo per scoprire cosa è andato esattamente storto. Ecco per cosa sono create le classi eccezionali personalizzate.

    
risposta data 27.04.2016 - 13:15
fonte

Leggi altre domande sui tag