Acabo de notar esta pregunta y quería agregar mi $ .02 a esto.
En el caso de Java, esta no es realmente una opción. El error de "código inalcanzable" no proviene del hecho de que los desarrolladores de JVM pensaron en proteger a los desarrolladores de cualquier cosa, o estar más alerta, sino de los requisitos de la especificación de JVM.
Tanto el compilador de Java como la JVM utilizan lo que se denomina "mapas de pila", una información definida sobre todos los elementos de la pila, según lo asignado para el método actual. Se debe conocer el tipo de todas y cada una de las ranuras de la pila, de modo que una instrucción JVM no maltrate un elemento de un tipo por otro. Esto es muy importante para evitar que se utilice un valor numérico como puntero. Es posible, usando el ensamblaje de Java, intentar presionar / almacenar un número, pero luego abrir / cargar una referencia de objeto. Sin embargo, JVM rechazará este código durante la validación de la clase, es decir, cuando se crean mapas de pila y se prueba la coherencia.
Para verificar los mapas de la pila, la máquina virtual tiene que recorrer todas las rutas de código que existen en un método y asegurarse de que, independientemente de la ruta de código que se ejecute, los datos de la pila para cada instrucción concuerden con lo que ha empujado cualquier código anterior. / almacenado en la pila. Entonces, en el caso simple de:
Object a;
if (something) { a = new Object(); } else { a = new String(); }
System.out.println(a);
en la línea 3, JVM verificará que ambas ramas de 'if' solo se hayan almacenado en un (que es solo var # 0 local) algo que sea compatible con Object (ya que así es como el código de la línea 3 en adelante tratará la var # 0 local ).
Cuando el compilador llega a un código inalcanzable, no sabe muy bien qué estado podría estar la pila en ese punto, por lo que no puede verificar su estado. Ya no puede compilar el código en ese punto, ya que tampoco puede realizar un seguimiento de las variables locales, por lo que en lugar de dejar esta ambigüedad en el archivo de clase, produce un error fatal.
Por supuesto, una condición simple como if (1<2) lo engañará, pero no es realmente engañoso: le está dando una rama potencial que puede conducir al código, y al menos tanto el compilador como la VM pueden determinar cómo se pueden usar los elementos de la pila desde allí. en.
PD: No sé qué hace .NET en este caso, pero creo que también fallará la compilación. Normalmente, esto no será un problema para ningún compilador de código de máquina (C, C ++, Obj-C, etc.)