Controlador de excepciones no controlado en .NET 1.1

StackOverflow https://stackoverflow.com/questions/944

Pregunta

Mantengo una aplicación .NET 1.1 y una de las cosas que me han encomendado es asegurarme de que el usuario no vea ninguna notificación de error desagradable.

He agregado controladores a Application.ThreadException y AppDomain.CurrentDomain.UnhandledException, que se llaman.Mi problema es que el cuadro de diálogo de error CLR estándar todavía se muestra (antes de llamar al controlador de excepciones).

Jeff habla de este problema en su blog. aquí y aquí.Pero no hay solución.Entonces, ¿cuál es la forma estándar en .NET 1.1 de manejar excepciones no detectadas y mostrar un cuadro de diálogo amigable?

La respuesta de Jeff se marcó como correcta porque el enlace que proporcionó tiene la información más completa sobre cómo hacer lo necesario.

¿Fue útil?

Solución

Oh, en Windows Forms definitivamente deberías poder hacerlo funcionar.Lo único que debes tener en cuenta es que suceden cosas en diferentes hilos.

Tengo un artículo antiguo de Code Project aquí que debería ayudar:

Manejo de excepciones fácil de usar

Otros consejos

AppDomain.Excepción no controlada es un evento, no un controlador de excepciones global.Esto significa que, en el momento en que se genera, su aplicación ya se está yendo por el desagüe y no hay nada que pueda hacer al respecto, excepto realizar la limpieza y el registro de errores.

Lo que pasó detrás de escena es esto:El marco detectó la excepción, subió la pila de llamadas hasta la parte superior, no encontró ningún controlador que se recuperara del error, por lo que no pudo determinar si era seguro continuar con la ejecución.Entonces, comenzó la secuencia de cierre y desencadenó este evento como una cortesía hacia usted para que pueda presentar sus respetos a su proceso ya condenado.Esto sucede cuando una excepción no se controla en el hilo principal.

No existe una solución única para este tipo de error.Debe colocar un controlador de excepciones real (un bloque de captura) en sentido ascendente de todos los lugares donde ocurre este error y reenviarlo (por ejemplo) a un método/clase de controlador global que determinará si es seguro simplemente informar y continuar, según tipo de excepción y/o contenido.

Editar:Es posible desactivar (=piratear) el mecanismo de informe de errores integrado en Windows para que el cuadro de diálogo obligatorio "bloquear y grabar" no se muestre cuando la aplicación se caiga.Sin embargo, esto resulta efectivo para todo las aplicaciones del sistema, no sólo las suyas.

El comportamiento de las excepciones no controladas en una aplicación Windows Forms .NET 1.x depende de:

  • El tipo de hilo que arrojó la excepción.
  • Si ocurrió durante el procesamiento del mensaje de ventana
  • Si se adjuntó un depurador al proceso
  • La configuración del registro DbgJitDebugLaunchSetting
  • El indicador jitDebugging en App.Config
  • Si anuló el controlador de excepciones de Windows Forms
  • Si manejó el evento de excepción de CLR
  • La fase de la luna.

El comportamiento predeterminado de las excepciones no controladas es:

  • Si la excepción ocurre en el hilo principal al enviar mensajes de ventana, es interceptada por el controlador de excepciones de Windows Forms.
  • Si la excepción ocurre en el hilo principal al enviar mensajes de ventana, finalizará el proceso de la aplicación a menos que sea interceptada por el controlador de excepciones de Windows Forms.
  • Si la excepción se produce en un subproceso manual, de grupo de subprocesos o de finalizador, el CLR la traga.

Los puntos de contacto para una excepción no controlada son:

  • Manejador de excepciones de Windows Forms.
  • El modificador de registro de depuración JIT DbgJitDebugLaunchSetting.
  • El evento de excepción no controlado de CLR.

El manejo de excepciones integrado de Windows Form hace lo siguiente de forma predeterminada:

  • Detecta una excepción no controlada cuando:
    • La excepción está en el hilo principal y no hay ningún depurador adjunto.
    • Se produce una excepción durante el procesamiento de mensajes de ventana.
    • jitDebugging = false en App.Config.
  • Muestra un cuadro de diálogo al usuario y evita la finalización de la aplicación.

Puede desactivar este último comportamiento configurando jitDebugging = true en App.Config.Pero recuerde que esta puede ser su última oportunidad de detener la terminación de la aplicación.Entonces, el siguiente paso para detectar una excepción no controlada es registrarse en el evento Application.ThreadException, por ejemplo:

Application.ThreadException += new
Threading.ThreadExceptionHandler(CatchFormsExceptions);

Tenga en cuenta la configuración del registro DbgJitDebugLaunchSetting en HKEY_LOCAL_MACHINE\Software.NetFramework.Esto tiene uno de los tres valores que conozco:

  • 0:muestra el cuadro de diálogo del usuario que pregunta "depurar o finalizar".
  • 1:permite que la excepción pase para que CLR la resuelva.
  • 2:inicia el depurador especificado en la clave de registro DbgManagedDebugger.

En Visual Studio, vaya al menú Herramientas → Opciones → Depuración → JIT para establecer esta clave en 0 o 2.Pero un valor de 1 suele ser mejor en la máquina de un usuario final.Tenga en cuenta que se actúa sobre esta clave de registro antes del evento de excepción no controlada de CLR.

Este último evento es su última oportunidad de registrar una excepción no controlada.Se activa antes de que se hayan ejecutado los bloques Finalmente.Puede interceptar este evento de la siguiente manera:

AppDomain.CurrentDomain.UnhandledException += new
System.UnhandledExceptionEventHandler(CatchClrExceptions);

¿Es esta una aplicación de consola o una aplicación de Windows Forms?Si se trata de una aplicación de consola .NET 1.1, esto es, lamentablemente, por diseño: lo confirma un desarrollador de MSFT en el segunda publicación de blog a la que hiciste referencia:

Por cierto, en mi máquina 1.1 el ejemplo de MSDN tiene el resultado esperado;es sólo que la segunda línea no aparece hasta que hayas adjuntado un depurador (o no).En la versión 2, cambiamos las cosas para que el evento UnhandledException se active antes de que se conecte el depurador, que parece ser lo que la mayoría de la gente espera.

Parece que .NET 2.0 hace esto mejor (gracias a Dios), pero, sinceramente, nunca tuve tiempo de volver atrás y comprobarlo.

Es una aplicación de Windows Forms.Las excepciones detectadas por Application.ThreadException funcionan bien y no aparece el feo cuadro de excepción .NET (DE ACUERDO para terminar, Cancelar ¿depurar?¿A quién se le ocurrió eso??).

Recibí algunas excepciones que eso no detectaba y terminé yendo al evento AppDomain.UnhandledException que estaba causando problemas.Creo que he detectado la mayoría de esas excepciones y ahora las muestro en nuestro bonito cuadro de error.

Así que tendré que esperar que no haya otras circunstancias que provoquen que el controlador Application.ThreadException no detecte las excepciones.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top