Mandrin inaccessibleNorrisException

Est-il possible de construire un extrait de code en Java qui rendrait une hypothétique java.lang.ChuckNorrisExceptioninaccessible?

Les pensées qui me viennent à l'esprit utilisent par exemple des intercepteurs ou une programmation orientée aspect .

Je n'ai pas essayé cela, donc je ne sais pas si la JVM restreindrait quelque chose comme ça, mais peut-être pourriez-vous compiler du code qui lance ChuckNorrisException, mais au moment de l'exécution, fournissez une définition de classe ChuckNorrisExceptionqui ne prolonge pas Throwable .

MISE À JOUR:

Ça ne marche pas. Il génère une erreur de vérificateur:

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.

MISE À JOUR 2:

En fait, vous pouvez le faire fonctionner si vous désactivez le vérificateur de code d'octet! ( -Xverify:none)

MISE À JOUR 3:

Pour ceux qui suivent de chez eux, voici le script complet:

Créez les classes suivantes:

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

Compiler les classes:

javac -cp . TestVillain.java ChuckNorrisException.java

Courir:

java -cp . TestVillain
Gotcha!
The end.

Commentez "étend RuntimeException" et recompilez ChuckNorrisException.javauniquement :

javac -cp . ChuckNorrisException.java

Courir:

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.

Exécuter sans vérification:

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

Après avoir réfléchi à cela, j'ai réussi à créer une exception inaccessible. J'ai choisi de le nommer JulesWinnfield, cependant, plutôt que Chuck, parce que c'est une exception mère-champignon-pose-nuage. De plus, ce n'est peut-être pas exactement ce que vous aviez en tête, mais cela ne peut certainement pas être capturé. Observer:

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à! Exception non interceptée.

Production:

courir:

Dites «Quoi» encore! Je te défie! Je double osez-vous!

Résultat Java: 8

CONSTRUIRE AVEC SUCCÈS (temps total: 0 seconde)

Quand j'aurai un peu plus de temps, je verrai si je ne peux pas trouver autre chose aussi.

Vérifiez également ceci:

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

    }
}

Provoque un débordement de pile - encore une fois, les exceptions restent non détectées.

Avec une telle exception, il serait évidemment obligatoire d'utiliser un System.exit(Integer.MIN_VALUE);du constructeur car c'est ce qui se passerait si vous leviez une telle exception;)

Tout code peut intercepter Throwable. Donc non, quelle que soit l'exception que vous créez, elle sera une sous-classe de Throwable et sera sujette à être interceptée.

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

(Certes, techniquement, cette exception n'est jamais levée, mais un véritable ChuckNorrisExceptionne peut pas être levé - il vous lance en premier.)

Toute exception que vous lancez doit étendre Throwable, afin qu'elle puisse toujours être interceptée. La réponse est donc non.

Si vous voulez le rendre difficile à manipuler, vous pouvez remplacer les méthodes getCause(), getMessage(), getStackTrace(), toString()de jeter un autre java.lang.ChuckNorrisException.

Ma réponse est basée sur l'idée de @ jtahlborn, mais c'est un programme Java pleinement fonctionnel , qui peut être empaqueté dans un fichier JAR et même déployé sur votre serveur d'applications préféré dans le cadre d'une application Web .

Tout d'abord, définissons la ChuckNorrisExceptionclasse afin qu'elle ne plante pas la JVM depuis le début (Chuck aime vraiment planter les 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);
    }
}

Va maintenant en Expendablesclasse pour le construire:

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

Et enfin la Mainclasse pour botter les fesses:

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

Compilez-le et exécutez-le avec la commande suivante:

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

Vous obtiendrez la sortie suivante:

before
finally

Pas de surprise - c'est un coup de pied rond après tout :)

Dans le constructeur, vous pouvez démarrer un thread qui appelle à plusieurs reprises originalThread.stop (ChuckNorisException.this)

Le thread pourrait intercepter l'exception à plusieurs reprises mais continuerait à le lancer jusqu'à ce qu'il meure.

Non. Toutes les exceptions en Java doivent être de sous java.lang.Throwable- classe , et bien que ce ne soit pas une bonne pratique, vous pouvez intercepter tout type d'exception comme ceci:

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

Voir le java.lang.Throwable documentation pour plus d'informations.

Si vous essayez d'éviter les exceptions vérifiées (celles qui doivent être explicitement gérées), vous souhaiterez sous-classer Error ou RuntimeException.

En fait, la réponse acceptée n'est pas si agréable car Java doit être exécuté sans vérification, c'est-à-dire que le code ne fonctionnerait pas dans des circonstances normales.

AspectJ à la rescousse de la vraie solution !

Classe d'exception:

package de.scrum_master.app;

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

Aspect:

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

Exemple d'application:

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

Production:

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)

Une variante du thème est le fait surprenant que vous pouvez lever des exceptions vérifiées non déclarées à partir du code Java. Comme il n'est pas déclaré dans la signature des méthodes, le compilateur ne vous permet pas d'attraper l'exception elle-même, bien que vous puissiez l'attraper en tant que java.lang.Exception.

Voici une classe d'aide qui vous permet de lancer n'importe quoi, déclaré ou non:

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());Lance maintenant une exception ChuckNorrisException, mais le compilateur se plaint dans

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

sur la capture d'une exception qui n'est pas levée si ChuckNorrisException est une exception vérifiée.

Les seuls ChuckNorrisExceptions en Java devraient être OutOfMemoryErroret StackOverflowError.

Vous pouvez réellement les "attraper" dans le sens où un catch(OutOfMemoryError ex) s'exécutera au cas où l'exception serait levée, mais ce bloc renverra automatiquement l'exception à l'appelant.

Je ne pense pas que cela public class ChuckNorrisError extends Errorfasse l'affaire, mais vous pouvez essayer. Je n'ai trouvé aucune documentation sur l'extensionError

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

Oui, et voici la réponse: Concevez votre java.lang.ChuckNorrisExceptiontel qu'il ne soit pas une instance de java.lang.Throwable. Pourquoi? Un objet non déployable est par définition inaccessible car vous ne pouvez jamais attraper quelque chose qui ne peut jamais être lancé.

Vous pouvez garder ChuckNorris interne ou privé et l'encapsuler ou le faire glisser ...

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

Deux problèmes fondamentaux avec la gestion des exceptions en Java sont qu'il utilise le type d'une exception pour indiquer si une action doit être prise en fonction de celle-ci, et que tout ce qui prend une action en fonction d'une exception (c'est-à-dire "l'attraper" est supposé résoudre la condition sous-jacente. Il serait utile d'avoir un moyen par lequel un objet d'exception pourrait décider quels gestionnaires devraient exécuter, et si les gestionnaires qui ont exécuté jusqu'à présent ont suffisamment nettoyé les choses pour que la méthode actuelle satisfasse ses conditions de sortie. Bien que cela puisse être utilisé pour créer des exceptions "inaccessibles", deux utilisations plus importantes consisteraient à (1) créer des exceptions qui ne seront considérées comme gérées que lorsqu'elles sont détectées par un code qui sait réellement comment les traiter,finallyFooExceptionpendant un finallybloc pendant le déroulement d'un BarException, les deux exceptions doivent se propager dans la pile des appels; les deux doivent être capturables, mais le déroulement doit se poursuivre jusqu'à ce que les deux soient capturés). Malheureusement, je ne pense pas qu'il y aurait moyen de faire fonctionner le code de gestion des exceptions de cette manière sans casser les choses.

Il est facilement possible de simuler une exception non interceptée sur le thread actuel. Cela déclenchera le comportement normal d'une exception non interceptée et fera donc le travail sémantiquement. Cependant, cela n'arrêtera pas nécessairement l'exécution du thread actuel, car aucune exception n'est réellement levée.

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

Ceci est en fait utile dans des situations (très rares), par exemple lorsqu'une Errormanipulation appropriée est requise, mais la méthode est invoquée à partir d'un framework capturant (et rejetant) any Throwable.

Appelez System.exit (1) dans le finalize, et jetez simplement une copie de l'exception de toutes les autres méthodes, afin que le programme se termine.