ChuckNorrisException inalcanzable

¿Es posible construir un fragmento de código en Java que pueda hacer que un hipotético sea java.lang.ChuckNorrisExceptionindescifrable?

Los pensamientos que se me ocurrieron están utilizando, por ejemplo, interceptores o programación orientada a aspectos .

No lo he intentado, así que no sé si la JVM restringiría algo como esto, pero tal vez podría compilar código que arroje ChuckNorrisException, pero en tiempo de ejecución proporcionar una definición de clase ChuckNorrisExceptionque no extienda Throwable .

ACTUALIZAR:

No funciona Genera un error de verificador:

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.

ACTUALIZACIÓN 2:

En realidad, puede hacer que esto funcione si deshabilita el verificador de código de bytes. ( -Xverify:none)

ACTUALIZACIÓN 3:

Para aquellos que siguen desde casa, aquí está el script completo:

Crea las siguientes clases:

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

Compilar clases:

javac -cp . TestVillain.java ChuckNorrisException.java

Correr:

java -cp . TestVillain
Gotcha!
The end.

Comente "extiende RuntimeException" y recompile ChuckNorrisException.javasolo :

javac -cp . ChuckNorrisException.java

Correr:

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.

Ejecutar sin verificación:

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

Después de haber reflexionado sobre esto, he creado con éxito una excepción inalcanzable. Elegí nombrarlo JulesWinnfield, sin embargo, en lugar de Chuck, porque es una excepción de hongo-nube-colocación-madre. Además, puede que no sea exactamente lo que tenía en mente, pero ciertamente no se puede atrapar. Observar:

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! Excepción no capturada.

Salida:

correr:

¡Dí que otra vez! ¡Yo Te reto! ¡Te recontra reto!

Resultado Java: 8

CONSTRUIR CON ÉXITO (tiempo total: 0 segundos)

Cuando tenga un poco más de tiempo, veré si no puedo pensar en otra cosa también.

Además, mira esto:

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 desbordamiento de la pila; nuevamente, las excepciones permanecen sin capturar.

Con tal excepción, obviamente sería obligatorio usar un System.exit(Integer.MIN_VALUE);del constructor porque esto es lo que sucedería si lanzara tal excepción;)

Cualquier código puede atrapar Throwable. Entonces, no, cualquier excepción que cree será una subclase de Throwable y estará sujeta a ser atrapada.

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

(De acuerdo, técnicamente , esta excepción nunca se lanza, pero ChuckNorrisExceptionno se puede lanzar una adecuada , te lanza primero).

Cualquier excepción que arrojes tiene que extender Throwable, por lo que siempre se puede atrapar. Entonces la respuesta es no.

Si desea hacer que sea difícil de manejar, puede reemplazar los métodos getCause(), getMessage(), getStackTrace(), toString()para lanzar otra java.lang.ChuckNorrisException.

Mi respuesta se basa en la idea de @ jtahlborn, pero es un programa Java totalmente funcional , que puede empaquetarse en un archivo JAR e incluso implementarse en su servidor de aplicaciones favorito como parte de una aplicación web .

En primer lugar, definamos la ChuckNorrisExceptionclase para que no bloquee JVM desde el principio (a Chuck realmente le encanta chocar JVMs 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);
    }
}

Ahora pasa a Expendablesclase para construirlo:

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

Y finalmente la Mainclase para patear un trasero:

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

Compile y ejecútelo con el siguiente comando:

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

Obtendrá el siguiente resultado:

before
finally

No es de extrañar, es una patada giratoria después de todo :)

En el constructor, puede iniciar un hilo que llama repetidamente originalThread.stop (ChuckNorisException.this)

El hilo podría atrapar la excepción repetidamente, pero seguiría lanzándolo hasta que muera.

No. Todas las excepciones en Java deben ser de subclase java.lang.Throwable, y aunque puede que no sea una buena práctica, puede detectar todo tipo de excepción de esta manera:

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

Consulte la documentación de java.lang.Throwable para obtener más información.

Si está tratando de evitar las excepciones marcadas (las que deben manejarse explícitamente), entonces querrá subclasificar Error o RuntimeException.

En realidad, la respuesta aceptada no es tan buena porque Java debe ejecutarse sin verificación, es decir, el código no funcionaría en circunstancias normales.

¡AspectJ al rescate por la solución real !

Clase de excepción:

package de.scrum_master.app;

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

Aspecto:

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

Aplicación de muestra:

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

Salida:

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 es el hecho sorprendente de que puede lanzar excepciones comprobadas no declaradas del código Java. Como no se declara en la firma de métodos, el compilador no le permitirá detectar la excepción en sí, aunque puede capturarla como java.lang.Exception.

Aquí hay una clase auxiliar que te permite lanzar cualquier cosa, declarada o no:

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

Ahora throw SneakyThrow.sneak(new ChuckNorrisException());arroja una ChuckNorrisException, pero el compilador se queja en

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

sobre la captura de una excepción que no se produce si ChuckNorrisException es una excepción marcada.

Los únicos ChuckNorrisExceptions en Java deberían ser OutOfMemoryErrory StackOverflowError.

De hecho, puedes "atraparlos" de la manera que catch(OutOfMemoryError ex) se ejecutará a en caso de que se lance la excepción, pero ese bloque automáticamente arrojará la excepción a la persona que llama.

No creo que eso public class ChuckNorrisError extends Errorfuncione, pero podrías intentarlo. No encontré documentación sobre extenderError

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

Sí, y aquí está la respuesta: diseñe su java.lang.ChuckNorrisExceptiontal que no sea una instancia dejava.lang.Throwable . ¿Por qué? Un objeto que no se puede lanzar es inalcanzable por definición porque nunca se puede atrapar algo que nunca se puede lanzar.

Puede mantener a ChuckNorris interno o privado y encapsularlo o tragarlo ...

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

Dos problemas fundamentales con el manejo de excepciones en Java son que usa el tipo de una excepción para indicar si se debe tomar una acción basada en ella, y que cualquier cosa que tome acción basada en una excepción (es decir, "atraparlo") se supone que se resuelve La condición subyacente. Sería útil tener un medio por el cual un objeto de excepción podría decidir qué manejadores deberían ejecutarse, y si los manejadores que se han ejecutado hasta ahora han limpiado las cosas lo suficiente como para que el presente método satisfaga sus condiciones de salida. Si bien esto podría usarse para hacer excepciones "imposibles de capturar", dos usos más grandes serían (1) hacer excepciones que solo se considerarán manejadas cuando estén atrapadas por un código que realmente sepa cómo lidiar con ellas,finallyFooExceptionfinallybloque durante el desenrollado de a BarException, ambas excepciones deben propagarse por la pila de llamadas; ambos deben ser atrapables, pero el desenrollado debe continuar hasta que ambos hayan sido atrapados). Desafortunadamente, no creo que haya alguna forma de hacer que el código existente de manejo de excepciones funcione de esa manera sin romper las cosas.

Es posible simular fácilmente una excepción no detectada en el hilo actual. Esto activará el comportamiento regular de una excepción no detectada y, por lo tanto, hará el trabajo semánticamente. Sin embargo, no necesariamente detendrá la ejecución del subproceso actual, ya que no se produce ninguna excepción.

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

Esto es realmente útil en situaciones (muy raras), por ejemplo, cuando Errorse requiere un manejo adecuado , pero el método se invoca desde un marco que captura (y descarta) cualquiera Throwable.

Llame a System.exit (1) en el finalize, y simplemente arroje una copia de la excepción de todos los demás métodos, para que el programa salga.