E 'possibile / buona idea ridurre la possibilità di arresto anomalo rilevando l'errore?

3

Ho una classe le implementazioni A che eseguirà un certo metodo di classe B . Esiste il requisito che questo A debba mai arrestarsi in modo anomalo durante l'esecuzione di questa operazione (che non è possibile, giusto?).

Per ridurre la possibilità di arresto anomalo, sto recuperando Throwable attorno all'operazione, in questo modo:

public void method(B b)
{
    try
    {
        b.operation
    }
    catch(Throwable e)
    {
        //Log e
        //Clean up stuff
    }
}

Le mie domande sono:

  • Sarebbe davvero utile per ridurre gli arresti anomali causati da una percentuale di% di co_de generata?
  • È una buona idea prendere sempre un Error ?
posta Adam 06.10.2014 - 16:18
fonte

4 risposte

11

Risposte semplici: No e no .

Ad esempio, la cattura di un OutOfMemoryError può essere negativa, in quanto senza memoria cosa potresti fare?

Inoltre, tutti gli altri errori indicano molto probabilmente un errore più grave in cui non puoi fare nulla.

Per riferimento vedi gli errori nel pacchetto java.lang e decidi per ognuno cosa farai quando lo prendi. Se sei felice scoprirai che forse ogni decimo errore potrebbe essere gestito da te.

    
risposta data 06.10.2014 - 16:21
fonte
3

Quando incontri un Error , significa in genere che il tuo programma si trova ora in uno stato indefinito: un file .class è danneggiato, o la memoria è completamente piena, oppure hai incontrato un bug interno nella JVM, o qualcosa di simile gravità. Chiediti: anche se prendi il Error per evitare un arresto immediato, è significativo continuare a correre in queste circostanze? Puoi fidarti che il programma si comporti correttamente dopo? Cosa puoi fare per effettivamente gestire un Error una volta che lo prendi?

Se il tuo requisito "mai crash" significa "non smettere mai di eseguire", quindi con tutti i mezzi, accedi e continua. Chiaramente, il tuo cliente crede che un programma non valido sia migliore di quello terminato. Ma se "mai andare in crash" significa "non smettere mai di funzionare", dovresti concentrare i tuoi sforzi difensivi altrove per evitare che il Error si verifichi in primo luogo, lasciare che il programma si interrompa in qualche modo e configurare automaticamente il tuo server riavviare il programma se ciò accade.

    
risposta data 07.10.2014 - 04:49
fonte
1

In generale, non dovresti MAI catturare cose come Exception, Throwable o Error, ma solo quelle sottoclassi specifiche di quelle che la tua applicazione può ragionevolmente aspettarsi di gestire e sopravvivere (o almeno registrare qualcosa di utile prima di arrestarsi). < br> La gestione delle eccezioni dovrebbe essere proprio quella, gestire le condizioni di errore e gestirle in modo tale che l'applicazione possa continuare a funzionare o segnalare ciò che è accaduto prima di terminare.
Non è pensato per mascherare gli errori, nascondere i problemi e quindi provare a continuare come se nulla fosse accaduto. Non solo funzionerà raramente (farà girare la sua brutta testa da qualche parte nell'applicazione presto, peggiorando il problema dato che ora hai ancora più corruzione nel tuo stato e / o dati, ma ora hai un problema che è molto più difficile rintracciare, eseguire il debug e infine correggere.

    
risposta data 07.10.2014 - 16:27
fonte
0

Non scriverò un programma java senza prendere Throwable al livello superiore di ogni processo. L'errore rilevato è (per definizione) imprevisto, ed è un bug che deve essere registrato e corretto. Il gli errori ti prendono in questo modo ti ti sorprenderanno e non lo farai mai impara da loro a meno che tu non faccia ogni possibile tentativo di ottenere il ritorna dal mondo reale al tuo desk di sviluppo.

    
risposta data 08.10.2014 - 06:47
fonte

Leggi altre domande sui tag