c# - Catch no realiza su código

silverlight windows-phone-8.1

Question

Estoy desarrollando la aplicación C # para Windows Phone 8.1 (Silverlight). Últimamente me he encontrado con el problema relacionado con la aplicación para conciliar el sueño y los guiones gráficos.

La construcción es la siguiente:

class X : DependencyObject
{
public static readonly DependencyProperty vProperty =
DependencyProperty.Register("v", typeof(double), typeof(X), new PropertyMetadata(0.0));
public double v
{
get
{
return (double)GetValue(vProperty);
}
set
{
SetValue(vProperty, value);
}
}
private Storyboard _storyboard;
void Prepare()
{
_storyboard = new Storyboard();
var animation= new DoubleAnimation
{
From = 0,
To = 1,
BeginTime = 0,
Duration = 0,
};
_storyboard.Children.Add(animation);
Storyboard.SetTarget(animation, this);
Storyboard.SetTargetProperty(animation, vProperty);
}
void Go()
{
_storyboard.Begin();
}
}

Hay una excepción NullReferenceException lanzada desde el interior de _storyboard.Begin () si la aplicación se coloca en segundo plano entre "Prepare" y "Go" (aproximadamente 10% de velocidad de reproducción). Por supuesto, termina con crash.

No pude determinar la fuente del problema y como necesito quickfix para eso, he decidido capturar esta NullRefereneceException en este raro escenario. Aquí es donde comienza la pregunta real. Cambié la implementación de "Ir" a:

 public void Go()
{
Debug.WriteLine("BreakPoint 1");
try
{
_storyboard.Begin();
}
catch (NullReferenceException)
{
Debug.WriteLine("BreakPoint 2");
}
}

Después, el bloqueo no es reproducible en absoluto, pero el problema es que "BreakPoint 2" nunca se golpea (tampoco se imprime en Salida). "BreakPoint 1" normalmente se golpea e imprime también. Al cambiar NullReferenceException por otro tipo de excepción (no por tipo de padre c) se vuelve a producir la falla.

Entonces ... ¿Qué está pasando aquí? ¿Este bloqueo está en caché o no? ¿Qué tipo de comportamiento extraño es ese? ¿Es seguro asumir que funcionará como se espera?

Pregunta adicional: ¿Tal vez sabes por qué el código original falla en primer lugar?

EDITAR: El trazo del final de la pila de internalException de TargetInvocationExceptions se ve de la siguiente manera:

 at MS.Internal.XcpImports.CheckHResult(UInt32 hr)
at MS.Internal.XcpImports.Storyboard_Begin(Storyboard storyboard)
at System.Windows.Media.Animation.Storyboard.Begin()
at X.Go()

Answer 1

Sé que has dicho que has intentado utilizar tipos principales para NullReferenceException, pero intenta lo siguiente sin ejecutar el depurador:

public void Go()
{
Debug.WriteLine("BreakPoint 1");
try
{
_storyboard.Begin();
}
catch (Exception)
{
Debug.WriteLine("BreakPoint 2");
System.Diagnostics.Debugger.Break();
}
}

Mi sospecha es que la captura no se activa porque se está ejecutando desde dentro del depurador. Pruebe también System.Diagnostics.Debugger.Launch(); en la captura si .Break(); No funciona. Y finalmente también prueba throw; en la captura si .Launch(); No funciona.

Si el depurador intenta iniciarse en cualquier caso, entonces tiene otra pista.

ACTUALIZAR :

No puedo darle todas las razones por las que esto podría suceder, ya que puede que no sea posible determinar con precisión qué es lo que está causando en su situación.

He visto un comportamiento como este debido al uso de multihilo. El subprocesamiento múltiple puede comportarse de manera diferente cuando se ejecuta con un depurador conectado y sin él. Los problemas de sincronización y las condiciones de carrera pueden evitar que se produzcan excepciones mientras se encuentra en el depurador, que de otro modo podría ocurrir con frecuencia cuando no hay un depurador conectado.

También encontré instancias en las que System.Diagnostics.Debugger.IsAttached se usó en código de terceros e incluso en el código de mi equipo, lo que provocó que la aplicación se comportara de manera diferente en función de las declaraciones if que utilizaban esta comprobación.

Y, por último, he tenido momentos en los que no podía encontrar una razón específica por la cual el comportamiento estaba ocurriendo. Aprendí a usar el método System.Diagnostics.Debugger.Break() cada vez que veo el comportamiento exhibido de manera diferente dependiendo de si un depurador está conectado o no. Algunas veces es solo una corazonada .