ChuckNorrisException non recuperabile

È possibile costruire un frammento di codice in Java che renderebbe un ipotetico java.lang.ChuckNorrisExceptionirraggiungibile?

I pensieri che mi sono venuti in mente stanno usando, ad esempio, intercettori o programmi orientati all'aspetto .

Non ho provato questo, quindi non so se la JVM limiterebbe qualcosa del genere, ma forse potresti compilare il codice che genera ChuckNorrisException, ma in fase di esecuzione fornire una definizione di classe di ChuckNorrisExceptioncui non si estende Throwable .

AGGIORNARE:

Non funziona Genera un errore verificatore:

Exception in thread "main" java.lang.VerifyError: (class: TestThrow, method: ma\
in signature: ([Ljava/lang/String;)V) Can only throw Throwable objects
Could not find the main class: TestThrow.  Program will exit.

AGGIORNAMENTO 2:

In realtà, puoi farlo funzionare se disabiliti il ​​verificatore del codice byte! ( -Xverify:none)

AGGIORNAMENTO 3:

Per quelli che seguono da casa, ecco lo script completo:

Creare le seguenti classi:

public class ChuckNorrisException
    extends RuntimeException // <- Comment out this line on second compilation
{
    public ChuckNorrisException() { }
}

public class TestVillain {
    public static void main(String[] args) {
        try {
            throw new ChuckNorrisException();
        }
        catch(Throwable t) {
            System.out.println("Gotcha!");
        }
        finally {
            System.out.println("The end.");
        }
    }
}

Compilare le classi:

javac -cp . TestVillain.java ChuckNorrisException.java

Correre:

java -cp . TestVillain
Gotcha!
The end.

Commenta "estende RuntimeException" e ricompila ChuckNorrisException.javasolo :

javac -cp . ChuckNorrisException.java

Correre:

java -cp . TestVillain
Exception in thread "main" java.lang.VerifyError: (class: TestVillain, method: main signature: ([Ljava/lang/String;)V) Can only throw Throwable objects
Could not find the main class: TestVillain.  Program will exit.

Esegui senza verifica:

java -Xverify:none -cp . TestVillain
The end.
Exception in thread "main"

Dopo aver riflettuto su questo, ho creato con successo un'eccezione irraggiungibile. Ho scelto di chiamarlo JulesWinnfield, invece, piuttosto che Chuck, perché è un'eccezione madre fungo-nuvola-posa-nuvola. Inoltre, potrebbe non essere esattamente quello che avevi in ​​mente, ma sicuramente non può essere colto. Osservare:

public static class JulesWinnfield extends Exception
{
    JulesWinnfield()
    {
        System.err.println("Say 'What' again! I dare you! I double dare you!");
        System.exit(25-17); // And you shall know I am the LORD
    }
}


public static void main(String[] args)
{       
    try
    {
        throw new JulesWinnfield();
    } 
    catch(JulesWinnfield jw)
    {
        System.out.println("There's a word for that Jules - a bum");
    }
}

Et voilà! Eccezione non rilevata.

Produzione:

correre:

Dì di nuovo "Cosa"! Ti sfido! Ti do il doppio coraggio!

Risultato Java: 8

BUILD SUCCESSFUL (tempo totale: 0 secondi)

Quando avrò ancora un po 'di tempo, vedrò se non riesco a trovare anche qualcos'altro.

Inoltre, controlla questo:

public static class JulesWinnfield extends Exception
{
    JulesWinnfield() throws JulesWinnfield, VincentVega
    {
        throw new VincentVega();
    }
}

public static class VincentVega extends Exception
{
    VincentVega() throws JulesWinnfield, VincentVega
    {
        throw new JulesWinnfield();
    }
}


public static void main(String[] args) throws VincentVega
{

    try
    {
        throw new JulesWinnfield();
    }
    catch(JulesWinnfield jw)
    {

    }
    catch(VincentVega vv)
    {

    }
}

Provoca un overflow dello stack: di nuovo, le eccezioni rimangono non rilevate.

Con una tale eccezione sarebbe ovviamente obbligatorio usare un System.exit(Integer.MIN_VALUE);dal costruttore perché questo è ciò che accadrebbe se si lanciasse una tale eccezione;)

Qualsiasi codice può essere intercettato. Quindi no, qualunque eccezione tu crei sarà una sottoclasse di Throwable e sarà soggetta ad essere catturata.

public class ChuckNorrisException extends Exception {
    public ChuckNorrisException() {
        System.exit(1);
    }
}

(Certo, tecnicamente questa eccezione non viene mai effettivamente lanciata, ma un vero e proprio ChuckNorrisExceptionnon può essere lanciato - ti lancia prima.)

Qualsiasi eccezione lanciata deve estendere Throwable, in modo che possa essere sempre catturata. Quindi la risposta è no.

Se vuoi renderlo difficile da gestire, puoi ignorare i metodi getCause(), getMessage(), getStackTrace()e toString()lanciarne un altro java.lang.ChuckNorrisException.

La mia risposta si basa sull'idea di @ jtahlborn, ma è un programma Java perfettamente funzionante , che può essere impacchettato in un file JAR e persino distribuito al tuo server delle applicazioni preferito come parte di un'applicazione web .

Prima di tutto, definiamo la ChuckNorrisExceptionclasse in modo che non blocchi JVM dall'inizio (Chuck ama davvero il crash JVM BTW :)

package chuck;

import java.io.PrintStream;
import java.io.PrintWriter;

public class ChuckNorrisException extends Exception {

    public ChuckNorrisException() {
    }

    @Override
    public Throwable getCause() {
        return null;
    }

    @Override
    public String getMessage() {
        return toString();
    }

    @Override
    public void printStackTrace(PrintWriter s) {
        super.printStackTrace(s);
    }

    @Override
    public void printStackTrace(PrintStream s) {
        super.printStackTrace(s);
    }
}

Ora va in Expendablesclasse per costruirlo:

package chuck;

import javassist.*;

public class Expendables {

    private static Class clz;

    public static ChuckNorrisException getChuck() {
        try {
            if (clz == null) {
                ClassPool pool = ClassPool.getDefault();
                CtClass cc = pool.get("chuck.ChuckNorrisException");
                cc.setSuperclass(pool.get("java.lang.Object"));
                clz = cc.toClass();
            }
            return (ChuckNorrisException)clz.newInstance();
        } catch (Exception ex) {
            throw new RuntimeException(ex);
        }
    }
}

E infine la Mainclasse per calciare un calcio:

package chuck;

public class Main {

    public void roundhouseKick() throws Exception {
        throw Expendables.getChuck();
    }

    public void foo() {
        try {
            roundhouseKick();
        } catch (Throwable ex) {
            System.out.println("Caught " + ex.toString());
        }
    }

    public static void main(String[] args) {
        try {
            System.out.println("before");
            new Main().foo();
            System.out.println("after");
        } finally {
            System.out.println("finally");
        }
    }
}

Compilalo ed eseguilo con il seguente comando:

java -Xverify:none -cp .:<path_to_javassist-3.9.0.GA.jar> chuck.Main

Otterrai il seguente output:

before
finally

Nessuna sorpresa - dopo tutto è un calcio circolare :)

Nel costruttore è possibile avviare un thread che chiama ripetutamente originalThread.stop (ChuckNorisException.this)

Il thread potrebbe catturare ripetutamente l'eccezione ma continuerebbe a lanciarla fino alla sua morte.

No. Tutte le eccezioni in Java devono essere suddivise in sottoclassi java.lang.Throwablee, sebbene possa non essere una buona pratica, puoi prendere ogni tipo di eccezione in questo modo:

try {
    //Stuff
} catch ( Throwable T ){
    //Doesn't matter what it was, I caught it.
}

Vedere la documentazione di java.lang.Thable per ulteriori informazioni.

Se stai cercando di evitare le eccezioni verificate (che devono essere gestite in modo esplicito), ti consigliamo di sottoclassare Error o RuntimeException.

In realtà la risposta accettata non è così piacevole perché Java deve essere eseguito senza verifica, cioè il codice non funzionerebbe in circostanze normali.

AspectJ in soccorso per la vera soluzione !

Classe di eccezione:

package de.scrum_master.app;

public class ChuckNorrisException extends RuntimeException {
    public ChuckNorrisException(String message) {
        super(message);
    }
}

Aspetto:

package de.scrum_master.aspect;

import de.scrum_master.app.ChuckNorrisException;

public aspect ChuckNorrisAspect {
    before(ChuckNorrisException chuck) : handler(*) && args(chuck) {
        System.out.println("Somebody is trying to catch Chuck Norris - LOL!");
        throw chuck;
    }
}

Applicazione di esempio:

package de.scrum_master.app;

public class Application {
    public static void main(String[] args) {
        catchAllMethod();
    }

    private static void catchAllMethod() {
        try {
            exceptionThrowingMethod();
        }
        catch (Throwable t) {
            System.out.println("Gotcha, " + t.getClass().getSimpleName() + "!");
        }
    }

    private static void exceptionThrowingMethod() {
        throw new ChuckNorrisException("Catch me if you can!");
    }
}

Produzione:

Somebody is trying to catch Chuck Norris - LOL!
Exception in thread "main" de.scrum_master.app.ChuckNorrisException: Catch me if you can!
    at de.scrum_master.app.Application.exceptionThrowingMethod(Application.java:18)
    at de.scrum_master.app.Application.catchAllMethod(Application.java:10)
    at de.scrum_master.app.Application.main(Application.java:5)

Una variante del tema è il fatto sorprendente che è possibile generare eccezioni controllate non dichiarate dal codice Java. Dato che non è dichiarato nella firma dei metodi, il compilatore non ti permetterà di catturare l'eccezione stessa, sebbene tu possa prenderla come java.lang.Exception.

Ecco una classe di supporto che ti consente di lanciare qualsiasi cosa, dichiarata o meno:

public class SneakyThrow {
  public static RuntimeException sneak(Throwable t) {
    throw SneakyThrow.<RuntimeException> throwGivenThrowable(t);
  }

  private static <T extends Throwable> RuntimeException throwGivenThrowable(Throwable t) throws T {
    throw (T) t;
  }
}

Ora throw SneakyThrow.sneak(new ChuckNorrisException());genera una ChuckNorrisException, ma il compilatore si lamenta

try {
  throw SneakyThrow.sneak(new ChuckNorrisException());
} catch (ChuckNorrisException e) {
}

sulla cattura di un'eccezione che non viene generata se ChuckNorrisException è un'eccezione controllata.

Le uniche ChuckNorrisExceptions in Java dovrebbero essere OutOfMemoryErroreStackOverflowError .

Puoi effettivamente "catturarli" nel modo in cui a catch(OutOfMemoryError ex) verrà eseguito nel caso in cui venga generata l'eccezione, ma quel blocco riproporrà automaticamente l'eccezione al chiamante.

Non credo che sia public class ChuckNorrisError extends Erroril trucco, ma potresti provarlo. Non ho trovato documentazione sull'estensioneError

Is it possible to construct a snippet of code in java that would make a hypothetical java.lang.ChuckNorrisException uncatchable?

Sì, ed ecco la risposta: progetta il tuo in modo java.lang.ChuckNorrisExceptiontale che non sia un'istanza di java.lang.Throwable. Perché? Un oggetto non lanciabile è irraggiungibile per definizione perché non puoi mai catturare qualcosa che non può mai essere lanciato.

Puoi mantenere ChuckNorris interno o privato e incapsularlo o trascinarlo ...

try { doChuckAction(); } catch(ChuckNorrisException cne) { /*do something else*/ }

Due problemi fondamentali con la gestione delle eccezioni in Java sono che utilizza il tipo di un'eccezione per indicare se un'azione deve essere basata su di essa e che si presume che tutto ciò che agisce in base a un'eccezione (ad esempio "intercettalo") si risolva la condizione sottostante. Sarebbe utile avere un mezzo con cui un oggetto di eccezione possa decidere quali gestori dovrebbero eseguire e se i gestori che hanno eseguito finora hanno ripulito le cose abbastanza perché il presente metodo soddisfi le sue condizioni di uscita. Mentre questo potrebbe essere usato per fare eccezioni "irraggiungibili", due usi più grandi sarebbero (1) fare eccezioni che saranno considerate gestite solo quando vengono catturate da un codice che effettivamente sa come gestirle,finallyFooExceptionfinallyblocco durante lo svolgimento di a BarException, entrambe le eccezioni dovrebbero propagarsi nello stack di chiamate; entrambi dovrebbero essere catchable, ma lo svolgimento dovrebbe continuare fino a quando entrambi non saranno stati catturati). Sfortunatamente, non penso che ci sarebbe alcun modo per far funzionare il codice di gestione delle eccezioni in quel modo senza rompere le cose.

È facilmente possibile simulare un'eccezione non rilevata sul thread corrente. Ciò attiverà il comportamento regolare di un'eccezione non rilevata, e quindi farà il lavoro semanticamente. Tuttavia, non interromperà necessariamente l'esecuzione del thread corrente, poiché non viene generata alcuna eccezione.

Throwable exception = /* ... */;
Thread currentThread = Thread.currentThread();
Thread.UncaughtExceptionHandler uncaughtExceptionHandler =
    currentThread.getUncaughtExceptionHandler();
uncaughtExceptionHandler.uncaughtException(currentThread, exception);
// May be reachable, depending on the uncaught exception handler.

Ciò è effettivamente utile in situazioni (molto rare), ad esempio quando Errorè richiesta una corretta gestione, ma il metodo è invocato da un framework che cattura (e scarta) qualsiasi Throwable.

Chiama System.exit (1) in finalize, e lancia una copia dell'eccezione da tutti gli altri metodi, in modo che il programma venga chiuso.