2012-06-08 13 views
8

Dato che io in fondo voglio eliminare l'uso eccezione controllata e trasformarli a runtime eccezioni, io normalmente fare qualcosa di simile:Sostituire un'eccezione controllata con un'eccezione di runtime?

try { 
    file.read(); 
} catch (IOException e){ 
    throw new RuntimeException(e); 
} 

Ci sono diversi svantaggi di fare questo, ma quello che mi ha la irrita la maggior parte è che la mia eccezione di runtime dovrebbe contenere uno stacktrace nidificato. Fondamentalmente mi piacerebbe rilanciare la "IOException" come RuntimeException (o "IORuntimeException") con il messaggio originale e lo stacktrace, così posso evitare lo stacktrace annidato inutile. Il "fatto" che ho rigettato l'eccezione da qualche parte nel mezzo sembra solo un rumore inutile per me.

È possibile? C'è qualche libreria che fa questo?

+0

È [questo] (http://robaustin.wikidot.com/rethrow-exceptions) utile? –

+2

Se sei irritato dagli stack nidificati nidificati, odieresti la maggior parte dei framework e delle librerie, che tendono ad usarli ampiamente. Mi ci sarei abituato se fossi in te. – artbristol

+0

@KazekageGaara, buono. Lo manterrei in precedenza se lo pubblichi come risposta. – missingfaktor

risposta

4

Project Lombok consente di disabilitare completamente le eccezioni controllate.

+2

Abbastanza corretto, ma per me è troppo di un trucco. Preferisco semplicemente farlo da qualche parte – krosenvold

+3

Dubito che ci sia una soluzione non hacker al problema che stai cercando di risolvere. – missingfaktor

3
class IORuntimeException extends RuntimeException { 

    final IOException ioex; 

    public IORuntimeException(IOException ioex) { 
     this.ioex = ioex; 
    } 

    @Override 
    public String getMessage() { 
     return ioex.getMessage(); 
    } 

    @Override 
    public StackTraceElement[] getStackTrace() { 
     return ioex.getStackTrace(); 
    } 

    //@Override 
    // ... 
} 

(classe completa disponibile here, come prodotto da Eclipse "Generate metodi delegato" macro.)

Usage:

try { 
    ... 
} catch (IOException ioex) { 
    throw new IORuntimeException(ioex); 
} 
+0

Il problema con questo approccio è che non può essere generalizzato per nessun tipo 'Exception', e quindi causa troppo numero di codice e duplicazione del codice. – missingfaktor

+0

Bene, puoi sempre fare [questo] (http://ideone.com/9OOwd). – aioobe

+0

Sì, ma le informazioni sul tipo sono perse. Solo se Java avesse generato generici reificati ... allora avremmo potuto farlo con i generici. – missingfaktor

3

Follow up dal mio commento. Ecco uno article che deve far luce sul problema. Usa sun.misc.Unsafe per rilanciare le eccezioni senza avvolgerle.

2

Se state pensando di utilizzo di altra risposta non sicuri (mi raccomando no, ma in ogni caso), un'altra opzione è quella di abusare di farmaci generici di lanciare un'eccezione controllata con questo paio male di metodi (da http://james-iry.blogspot.co.uk/2010/08/on-removing-java-checked-exceptions-by.html):

@SuppressWarnings("unchecked") 
    private static <T extends Throwable, A> 
    A pervertException(Throwable x) throws T { 
     throw (T) x; 
    } 


    public static <A> A chuck(Throwable t) { 
     return Unchecked. 
     <RuntimeException, A>pervertException(t); 
    } 

È inoltre possibile controllare com.google.common.base.Throwables.getRootCause(Throwable) e stampare solo la traccia dello stack (radice).

0

suona come è effettivamente necessario eccezioni controllate

0

Come di Java 8 c'è un altro modo:

try { 
    // some code that can throw both checked and runtime exception 
} catch (Exception e) { 
    throw rethrow(e); 
} 

@SuppressWarnings("unchecked") 
public static <T extends Throwable> RuntimeException rethrow(Throwable throwable) throws T { 
    throw (T) throwable; // rely on vacuous cast 
} 

* Maggiori informazioni here.

Problemi correlati