getta Eccezione in finalmente blocchi

Esiste un modo elegante per gestire le eccezioni lanciate in finallyblocco?

Per esempio:

try {
  // Use the resource.
}
catch( Exception ex ) {
  // Problem with the resource.
}
finally {
   try{
     resource.close();
   }
   catch( Exception ex ) {
     // Could not close the resource?
   }
}

Come eviti la try/ catchnel finallyblocco?

Di solito lo faccio in questo modo:

try {
  // Use the resource.
} catch( Exception ex ) {
  // Problem with the resource.
} finally {
  // Put away the resource.
  closeQuietly( resource );
}

Altrove:

protected void closeQuietly( Resource resource ) {
  try {
    if (resource != null) {
      resource.close();
    }
  } catch( Exception ex ) {
    log( "Exception during Resource.close()", ex );
  }
}

In genere utilizzo uno dei closeQuietlymetodi in org.apache.commons.io.IOUtils:

public static void closeQuietly(OutputStream output) {
    try {
        if (output != null) {
            output.close();
        }
    } catch (IOException ioe) {
        // ignore
    }
}

Se stai usando Java 7 e resourceimplementa AutoClosable, puoi farlo (usando InputStream come esempio):

try (InputStream resource = getInputStream()) {
  // Use the resource.
}
catch( Exception ex ) {
  // Problem with the resource.
}

Probabilmente un po 'esagerato, ma forse utile se lasci che le eccezioni si diffondano e non puoi registrare nulla dall'interno del tuo metodo (ad esempio perché è una libreria e preferiresti che il codice chiamante gestisca le eccezioni e la registrazione):

Resource resource = null;
boolean isSuccess = false;
try {
    resource = Resource.create();
    resource.use();
    // Following line will only run if nothing above threw an exception.
    isSuccess = true;
} finally {
    if (resource != null) {
        if (isSuccess) {
            // let close throw the exception so it isn't swallowed.
            resource.close();
        } else {
            try {
                resource.close();
            } catch (ResourceException ignore) {
                // Just swallow this one because you don't want it 
                // to replace the one that came first (thrown above).
            }
        }
    }
}

AGGIORNAMENTO: Ho esaminato questo aspetto un po 'di più e ho trovato un ottimo post sul blog di qualcuno che ci ha chiaramente pensato più di me: http://illegalargumentexception.blogspot.com/2008/10/java-how-not-to-make -mess-of-stream.html Fa un ulteriore passo avanti e combina le due eccezioni in una, che ho potuto vedere essere utile in alcuni casi.

A partire da Java 7 non è più necessario chiudere esplicitamente le risorse in un blocco finalmente , ma è possibile utilizzare la sintassi try -with-resources. L'istruzione try-with-resources è un'istruzione try che dichiara una o più risorse. Una risorsa è un oggetto che deve essere chiuso dopo che il programma ha terminato con esso. L'istruzione try-with-resources assicura che ogni risorsa sia chiusa alla fine dell'istruzione. Qualsiasi oggetto che implementa java.lang.AutoCloseable, che include tutti gli oggetti che implementano java.io.Closeable, può essere utilizzato come risorsa.

Assumi il codice seguente:

try( Connection con = null;
     Statement stmt = con.createStatement();
     Result rs= stmt.executeQuery(QUERY);)
{  
     count = rs.getInt(1);
}

Se si verifica un'eccezione, il metodo di chiusura verrà chiamato su ciascuna di queste tre risorse nell'ordine opposto in cui sono state create. Significa che il metodo di chiusura verrà chiamato prima per ResultSetm, quindi per l'istruzione e alla fine per l'oggetto Connection.

È anche importante sapere che tutte le eccezioni che si verificano quando i metodi di chiusura vengono chiamati automaticamente vengono soppresse. Queste eccezioni soppresse possono essere recuperate dal metodo getsuppressed () definito nella classe Throwable .

Fonte: https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

Ignorare le eccezioni che si verificano in un blocco "finalmente" è generalmente una cattiva idea a meno che non si sappia quali saranno quelle eccezioni e quali condizioni rappresenteranno. Nel try/finallymodello di utilizzo normale , il tryblocco pone le cose in uno stato che il codice esterno non si aspetta e il finallyblocco ripristina lo stato di quelle cose a quello che il codice esterno si aspetta. Il codice esterno che cattura un'eccezione generalmente si aspetta che, nonostante l'eccezione, tutto sia stato ripristinato in un filenormalstato. Ad esempio, supponiamo che un codice avvii una transazione e quindi provi ad aggiungere due record; il blocco "finalmente" esegue un'operazione di "rollback se non eseguito il commit". Un chiamante potrebbe essere preparato affinché si verifichi un'eccezione durante l'esecuzione della seconda operazione di "aggiunta" e potrebbe aspettarsi che, se rileva tale eccezione, il database si troverà nello stato in cui si trovava prima di tentare l'una o l'altra operazione. Se, tuttavia, si verifica una seconda eccezione durante il rollback, potrebbero verificarsi problemi se il chiamante fa qualche ipotesi sullo stato del database. L'errore di rollback rappresenta una grave crisi, che non dovrebbe essere rilevata dal codice che si aspetta una semplice eccezione "Impossibile aggiungere record".

La mia inclinazione personale sarebbe quella di fare in modo che un metodo finalmente catturi le eccezioni che si verificano e le racchiuda in una "CleanupFailedException", riconoscendo che tale fallimento rappresenta un problema importante e tale eccezione non dovrebbe essere presa alla leggera.

Una soluzione, se le due eccezioni sono due classi differenti

try {
    ...
    }
catch(package1.Exception err)
   {
    ...
   }
catch(package2.Exception err)
   {
   ...
   }
finally
  {
  }

Ma a volte non puoi evitare questo secondo tentativo di cattura. ad esempio per chiudere un flusso

InputStream in=null;
try
 {
 in= new FileInputStream("File.txt");
 (..)// do something that might throw an exception during the analysis of the file, e.g. a SQL error
 }
catch(SQLException err)
 {
 //handle exception
 }
finally
 {
 //at the end, we close the file
 if(in!=null) try { in.close();} catch(IOException err) { /* ignore */ }
 }

Perché vuoi evitare il blocco aggiuntivo? Dato che il blocco finalmente contiene operazioni "normali" che possono generare un'eccezione E vuoi che il blocco finalmente venga eseguito completamente, DEVI intercettare le eccezioni.

Se non ti aspetti che il blocco finalmente generi un'eccezione e non sai comunque come gestire l'eccezione (dovresti semplicemente eseguire il dump della traccia dello stack) lascia che l'eccezione si muova nello stack delle chiamate (rimuovi il try-catch dalla fine bloccare).

Se vuoi ridurre la digitazione potresti implementare un blocco try-catch esterno "globale", che rileverà tutte le eccezioni lanciate nei blocchi finalmente:

try {
    try {
        ...
    } catch (Exception ex) {
        ...
    } finally {
        ...
    }

    try {
        ...
    } catch (Exception ex) {
        ...
    } finally {
        ...
    }

    try {
        ...
    } catch (Exception ex) {
        ...
    } finally {
        ...
    }
} catch (Exception ex) {
    ...
}

Dopo molte considerazioni, trovo il seguente codice migliore:

MyResource resource = null;
try {
    resource = new MyResource();
    resource.doSomethingFancy();
    resource.close(); 
    resource = null;  
} finally {
    closeQuietly(resource)
}

void closeQuietly(MyResource a) {
    if (a!=null)
        try {
             a.close();
        } catch (Exception e) {
             //ignore
        }
}

Quel codice garantisce quanto segue:

1. La risorsa viene liberata al termine del codice
2. Le eccezioni generate alla chiusura della risorsa non vengono consumate senza elaborarle.
3. Il codice non tenta di chiudere la risorsa due volte, non verrà creata alcuna eccezione non necessaria.

Se puoi, dovresti provare per evitare la condizione di errore per cominciare.

try{...}
catch(NullArgumentException nae){...}
finally
{
  //or if resource had some useful function that tells you its open use that
  if (resource != null) 
  {
      resource.Close();
      resource = null;//just to be explicit about it was closed
  }
}

Inoltre dovresti probabilmente rilevare solo le eccezioni da cui puoi ripristinare, se non riesci a recuperare, lascia che si propaghi al livello superiore del tuo programma. Se non puoi testare una condizione di errore, dovrai circondare il tuo codice con un blocco try catch come hai già fatto (anche se consiglierei di catturare ancora errori specifici previsti).

Potresti effettuare il refactoring in un altro metodo ...

public void RealDoSuff()
{
   try
   { DoStuff(); }
   catch
   { // resource.close failed or something really weird is going on 
     // like an OutOfMemoryException 
   }
}

private void DoStuff() 
{
  try 
  {}
  catch
  {
  }
  finally 
  {
    if (resource != null) 
    {
      resource.close(); 
    }
  }
}

Di solito lo faccio:

MyResource r = null;
try { 
   // use resource
} finally {   
    if( r != null ) try { 
        r.close(); 
    } catch( ThatSpecificExceptionOnClose teoc ){}
}

Motivazione: se ho finito con la risorsa e l'unico problema che ho è chiuderla, non c'è molto che posso fare al riguardo. Non ha nemmeno senso uccidere l'intero thread se ho comunque finito con la risorsa.

Questo è uno dei casi in cui, almeno per me, è sicuro ignorare l'eccezione selezionata.

Fino ad oggi non ho avuto problemi a usare questo idioma.

try {
    final Resource resource = acquire();
    try {
        use(resource);
    } finally {
        resource.release();
    }
} catch (ResourceException exx) {
    ... sensible code ...
}

Lavoro fatto. Nessun test nullo. Cattura singola, includi acquisisci e rilascia eccezioni. Ovviamente puoi usare l'idioma Execute Around e devi scriverlo solo una volta per ogni tipo di risorsa.

Passaggio Resourceda migliore risposta aCloseable

Implementazioni di flussi CloseableQuindi è possibile riutilizzare il metodo per tutti i flussi

protected void closeQuietly(Closeable resource) {
    if (resource == null) 
        return;
    try {
        resource.close();
    } catch (IOException e) {
        //log the exception
    }
}

Ho riscontrato una situazione simile in cui non potevo usare try con le risorse, ma volevo anche gestire l'eccezione proveniente dalla chiusura, non solo log e ignorarla come fa il meccanismo closeQuietly. nel mio caso non ho a che fare con un flusso di output, quindi l'errore alla chiusura è più interessante di un semplice flusso.

IOException ioException = null;
try {
  outputStream.write("Something");
  outputStream.flush();
} catch (IOException e) {
  throw new ExportException("Unable to write to response stream", e);
}
finally {
  try {
    outputStream.close();
  } catch (IOException e) {
    ioException = e;
  }
}
if (ioException != null) {
  throw new ExportException("Unable to close outputstream", ioException);
}