c# - Problemas de bloque Try-Catch-Finally con.NET4.5.1

Question

Tengo un código de prueba simple que funciona como se esperaba en .NET3.5, pero el mismo código se comporta completamente diferente en un proyecto creado con .NET4.5.1

class Program
{
static void Main(string[] args)
{
try
{
string a = null;
var x = a.Length;
}
catch (Exception ex)
{
throw;
}
finally
{
Console.WriteLine("This is the finally block.");
}
Console.WriteLine("You should not be here if an exception occured!");
}
}

En primer lugar, lo extraño es que la excepción de tipo NullReferenceException se ignora por completo en .NET4.5.1 cuando se ejecuta el archivo exe RELEASE compilado. Básicamente, no se produce ningún error, aunque en el modo de depuración se lanza la excepción.

En segundo lugar (y lo más importante), si el error es diferente de NullReferenceException, como "índice fuera de rango", por ejemplo, la excepción se produce como se esperaba, pero el bloque "finalmente" nunca se alcanza, lo que no es el Comportamiento que esperaba del bloque try-catch-finally. Probé en diferentes máquinas, e hice que otros dos colegas míos también lo intentaran y todos obtuvimos el mismo resultado.

Parece que o bien nunca entendí realmente el bloque try-catch-finally, o .NET4.5.1 maneja la excepción de una manera diferente, o hay algún error con .NET4.5.1. Todo lo que sé es que el código anterior funciona en .NET3.5 como esperaba que funcionara, pero parece que no obtengo el mismo resultado cuando lo ejecuto en .NET4.5.1.

¿Alguien puede arrojar algo de luz sobre esto? Estoy en una pérdida total en este momento.

EDITAR Basado en la respuesta de Eric J, pude resolver el problema NullReferenceException. Como hice 2 preguntas, crearé un nuevo hilo para la segunda pregunta. Problemas de bloque Try-Catch-Finally con .NET4.5.1

Answer 1

string a = null;
var x = a.Length;

En el modo RELEASE, el jitter (justo en el compilador de tiempo) puede probar que x nunca se hace referencia, por lo que es capaz de eliminar la asignación.

En el modo DEBUG, el jitter no realiza esa optimización.

Para forzar que se lance la excepción, haga algo con x (por ejemplo, como sugiere @Henk en los comentarios, WriteLine(x) ).

EDITAR

Eric Lippert señaló en los comentarios.

... Estoy tan sorprendido como nadie de que la fluctuación de elongaría una instrucción de longitud de cadena que podría lanzar. Eso me parece equivocado...

La optimización de jitter puede ser demasiado agresiva.