Nicht fangbare ChuckNorrisException

Ist es möglich , einen Codeausschnitt in Java zujava.lang.ChuckNorrisException erstellen , der eine Hypothese unauffindbar macht?

Gedanken, die mir in den Sinn kamen, verwenden zum Beispiel Interceptors oder aspektorientierte Programmierung .

Ich habe nicht versucht, damit ich weiß nicht , ob der JVM so etwas wie dies beschränken würde, aber vielleicht könnten Sie Code kompilieren , die werfen ChuckNorrisException, sondern zur Laufzeit eine Klassendefinition zur Verfügung stelle von ChuckNorrisExceptiondenen Throwable nicht erstreckt .

AKTUALISIEREN:

Es funktioniert nicht. Es wird ein Überprüfungsfehler generiert:

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.

UPDATE 2:

Tatsächlich können Sie dies zum Laufen bringen, wenn Sie den Bytecode-Verifizierer deaktivieren! ( -Xverify:none)

UPDATE 3:

Für diejenigen, die von zu Hause aus folgen, ist hier das vollständige Skript:

Erstellen Sie die folgenden Klassen:

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.");
        }
    }
}

Klassen kompilieren:

javac -cp . TestVillain.java ChuckNorrisException.java

Lauf:

java -cp . TestVillain
Gotcha!
The end.

Kommentieren Sie "erweitert RuntimeException" aus und kompilieren Sie ChuckNorrisException.javanur neu :

javac -cp . ChuckNorrisException.java

Lauf:

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.

Ohne Überprüfung ausführen:

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

Nachdem ich darüber nachgedacht habe, habe ich erfolgreich eine nicht abfangbare Ausnahme erstellt. Ich habe es JulesWinnfieldjedoch lieber als Chuck genannt, weil es eine Ausnahme ist, die Pilzwolken legt. Außerdem ist es vielleicht nicht genau das, was Sie sich vorgestellt haben, aber es kann sicherlich nicht gefangen werden. Beobachten:

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 voila! Nicht erfasste Ausnahme.

Ausgabe:

Lauf:

Sag noch mal "was! Du traust dich ja nicht! Ich wage dich doppelt!

Java Ergebnis: 8

ERFOLGREICH BAUEN (Gesamtzeit: 0 Sekunden)

Wenn ich etwas mehr Zeit habe, werde ich sehen, ob ich mir auch nichts anderes einfallen lassen kann.

Überprüfen Sie dies auch:

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)
    {

    }
}

Verursacht einen Stapelüberlauf - auch hier bleiben Ausnahmen nicht erfasst.

Mit einer solchen Ausnahme wäre es natürlich obligatorisch, ein System.exit(Integer.MIN_VALUE);vom Konstruktor zu verwenden, da dies passieren würde, wenn Sie eine solche Ausnahme auslösen würden;)

Jeder Code kann Throwable fangen. Also nein, jede Ausnahme, die Sie erstellen, wird eine Unterklasse von Throwable sein und kann abgefangen werden.

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

(Zugegeben, technisch gesehen wird diese Ausnahme nie wirklich ausgelöst, aber eine richtige ChuckNorrisExceptionkann nicht ausgelöst werden - sie wirft Sie zuerst.)

Jede Ausnahme, die Sie auslösen, muss Throwable erweitern, damit sie immer abgefangen werden kann. Die Antwort lautet also nein.

Wenn Sie es schwierig zu handhaben machen möchten, können Sie außer Kraft setzen Methoden getCause(), getMessage(), getStackTrace(), eine toString()andere zu werfen java.lang.ChuckNorrisException.

Meine Antwort basiert auf der Idee von @ jtahlborn, aber es ist ein voll funktionsfähiges Java- Programm, das in eine JAR- Datei gepackt und sogar als Teil einer Webanwendung auf Ihrem bevorzugten Anwendungsserver bereitgestellt werden kann .

Definieren wir zunächst die ChuckNorrisExceptionKlasse, damit die JVM nicht von Anfang an abstürzt (Chuck liebt es wirklich, JVMs übrigens zum Absturz zu bringen :)

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);
    }
}

Jetzt geht ExpendablesKlasse, um es zu konstruieren:

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);
        }
    }
}

Und schließlich die MainKlasse, um einen Hintern zu treten:

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");
        }
    }
}

Kompilieren Sie es und führen Sie es mit folgendem Befehl aus:

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

Sie erhalten folgende Ausgabe:

before
finally

Kein Wunder - es ist doch ein Roundhouse-Kick :)

Im Konstruktor können Sie einen Thread starten, der wiederholt aufruft originalThread.stop (ChuckNorisException.this)

Der Thread konnte die Ausnahme wiederholt abfangen, warf sie jedoch weiter, bis sie stirbt.

Nein. Alle Ausnahmen in Java müssen Unterklassen sein java.lang.Throwable. Auch wenn dies möglicherweise keine gute Vorgehensweise ist, können Sie jede Art von Ausnahme wie folgt abfangen:

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

Weitere Informationen finden Sie in der Dokumentation zu java.lang.Throwable .

Wenn Sie versuchen, aktivierte Ausnahmen zu vermeiden (solche, die explizit behandelt werden müssen), sollten Sie Error oder RuntimeException in Unterklassen unterteilen.

Eigentlich ist die akzeptierte Antwort nicht so schön, weil Java ohne Überprüfung ausgeführt werden muss, dh der Code würde unter normalen Umständen nicht funktionieren.

Aspekt zur Rettung für die echte Lösung !

Ausnahmeklasse:

package de.scrum_master.app;

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

Aspekt:

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;
    }
}

Beispielanwendung:

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!");
    }
}

Ausgabe:

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)

Eine Variante des Themas ist die überraschende Tatsache, dass Sie nicht deklarierte geprüfte Ausnahmen aus Java-Code auslösen können. Da es nicht in der Methodensignatur deklariert ist, lässt der Compiler Sie die Ausnahme selbst nicht abfangen, obwohl Sie sie als java.lang.Exception abfangen können.

Hier ist eine Hilfsklasse, mit der Sie alles werfen können, ob deklariert oder nicht:

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;
  }
}

throw SneakyThrow.sneak(new ChuckNorrisException());Löst jetzt eine ChuckNorrisException aus, aber der Compiler beschwert sich

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

Informationen zum Abfangen einer Ausnahme, die nicht ausgelöst wird, wenn ChuckNorrisException eine aktivierte Ausnahme ist.

Das einzige ChuckNorrisExceptions in Java sollte OutOfMemoryErrorund sein StackOverflowError.

Sie können sie tatsächlich "fangen", indem Sie a catch(OutOfMemoryError ex)ausführen, falls die Ausnahme ausgelöst wird, dieser Block die Ausnahme jedoch automatisch an den Aufrufer zurückgibt.

Ich denke nicht, dass public class ChuckNorrisError extends Errordas den Trick macht, aber Sie könnten es versuchen. Ich habe keine Dokumentation zur Erweiterung gefundenError

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

Ja, und hier ist die Antwort: Entwerfen Sie Ihre java.lang.ChuckNorrisExceptionso, dass es keine Instanz von ist java.lang.Throwable. Warum? Ein nicht werfbares Objekt ist per Definition nicht fangbar, da Sie niemals etwas fangen können, das niemals geworfen werden kann.

Sie können ChuckNorris intern oder privat halten und ihn einkapseln oder schlucken ...

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

Zwei grundlegende Probleme bei der Ausnahmebehandlung in Java bestehen darin, dass der Typ einer Ausnahme verwendet wird, um anzugeben, ob darauf basierende Maßnahmen ergriffen werden sollen, und dass angenommen wird, dass alles, was auf der Grundlage einer Ausnahme Maßnahmen ergreift (dh "fangen"), behoben wird die zugrunde liegende Bedingung. Es wäre nützlich, ein Mittel zu haben, mit dem ein Ausnahmeobjekt entscheiden könnte, welche Handler ausgeführt werden sollen, und ob die Handler, die bisher ausgeführt wurden, die Dinge so weit aufgeräumt haben, dass die vorliegende Methode ihre Ausgangsbedingungen erfüllt. Während dies verwendet werden könnte, um "nicht abfangbare" Ausnahmen zu machen, wären zwei größere Verwendungszwecke, (1) Ausnahmen zu machen, die nur dann behandelt werden, wenn sie von Code abgefangen werden, der tatsächlich weiß, wie man mit ihnen umgeht.finallyFooExceptionfinally Blocks während des Abwickelns von a BarExceptionsollten beide Ausnahmen den Aufrufstapel weitergeben. beide sollten fangbar sein, aber das Abwickeln sollte fortgesetzt werden, bis beide gefangen wurden). Leider glaube ich nicht, dass es eine Möglichkeit gibt, vorhandenen Code für die Ausnahmebehandlung so zu gestalten, ohne dass Probleme auftreten.

Es ist leicht möglich, eine nicht erfasste Ausnahme für den aktuellen Thread zu simulieren. Dies löst das reguläre Verhalten einer nicht erfassten Ausnahme aus und erledigt die Aufgabe somit semantisch. Die Ausführung des aktuellen Threads wird jedoch nicht unbedingt gestoppt, da tatsächlich keine Ausnahme ausgelöst wird.

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

Dies ist tatsächlich in (sehr seltenen) Situationen nützlich, beispielsweise wenn eine ordnungsgemäße ErrorBehandlung erforderlich ist, die Methode jedoch von einem Framework aus aufgerufen wird, das alle abfängt (und verwirft) Throwable.

Rufen Sie System.exit (1) in der auf finalizeund werfen Sie einfach eine Kopie der Ausnahme von allen anderen Methoden, damit das Programm beendet wird.