Controlador de excepciones no administradas en .NET 1.1

votos
23

Estoy manteniendo 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 hostil.

He agregado manejadores a Application.ThreadExceptiony AppDomain.CurrentDomain.UnhandledException, que son llamados. Mi problema es que el cuadro de diálogo de error CLR estándar todavía se muestra (antes de que se llame al controlador de excepciones).

Jeff habla sobre 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 para manejar excepciones no detectadas y mostrar un cuadro de diálogo amigable?

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

Publicado el 04/08/2008 a las 02:15
fuente por usuario
En otros idiomas...                            


5 respuestas

votos
11

Oh, en Windows Forms definitivamente deberías poder hacer que funcione. Lo único que debes vigilar es que las cosas sucedan en diferentes hilos.

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

Manejo de excepciones fácil de usar

Respondida el 04/08/2008 a las 05:31
fuente por usuario

votos
5

El comportamiento de excepción no controlada en una aplicación .NET 1.x de Windows Forms depende de:

  • El tipo de hilo que arrojó la excepción
  • Si ocurrió durante el procesamiento del mensaje de ventana
  • Si un depurador se adjuntó al proceso
  • La configuración de registro DbgJitDebugLaunchSetting
  • El indicador jitDebugging en App.Config
  • Si superó el controlador de excepción 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 se produce en el hilo principal al bombear mensajes de ventana, es interceptado por el manejador de excepciones de Windows Forms.
  • Si la excepción ocurre en el hilo principal al bombear mensajes de ventana, terminará el proceso de la aplicación a menos que sea interceptado por el manejador de excepciones de Windows Forms.
  • Si la excepción se produce en un hilo manual, de subprocesos o de finalizador, el CLR se lo traga.

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

  • Manejador de excepciones de Windows Forms.
  • El conmutador de registro JIT-debug DbgJitDebugLaunchSetting.
  • El evento de excepción no controlada CLR.

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

  • Captura una excepción no controlada cuando:
    • la excepción está en el hilo principal y no hay un depurador adjunto.
    • la excepción ocurre durante el procesamiento del mensaje de ventana.
    • jitDebugging = false en App.Config.
  • Muestra el 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 recuerda que esta puede ser tu última oportunidad para detener la finalización de la aplicación. Entonces, el siguiente paso para atrapar una excepción no controlada es registrarse para 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: deja pasar la excepción a través de CLR.
  • 2: inicia el depurador especificado en la clave de registro DbgManagedDebugger.

En Visual Studio, vaya al menú HerramientasOpcionesDepuraciónJIT para establecer esta clave en 0 o 2. Pero un valor de 1 generalmente es mejor en la máquina de un usuario final. Tenga en cuenta que esta clave de registro se actúa antes del evento de excepción CLR no controlada.

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

AppDomain.CurrentDomain.UnhandledException += new
System.UnhandledExceptionEventHandler(CatchClrExceptions);
Respondida el 20/09/2008 a las 16:52
fuente por usuario

votos
4

AppDomain.UnhandledException es un evento , no un controlador de excepción global. Esto significa que, en el momento en que se produce, su aplicación ya está en camino a la fuga, y no hay nada que pueda hacer al respecto, a excepción de la limpieza y el registro de errores.

Lo que sucedió detrás de escena es esto: el marco detectó la excepción, subió la pila de llamadas hasta la parte superior, no encontró controladores que se recuperaran del error, por lo que no pudo determinar si era seguro continuar la ejecución. Entonces, comenzó la secuencia de apagado y activó este evento como una cortesía para que pueda presentar sus respetos a su proceso ya condenado. Esto sucede cuando una excepción no se deja en el hilo principal.

No hay una solución de punto único para este tipo de error. Debe colocar un controlador de excepción real (un bloque de catch) en sentido ascendente de todos los lugares donde se produce este error y reenviarlo a (por ejemplo) un método / clase de controlador global que determinará si es seguro simplemente informar y continuar, en función de tipo de excepción y / o contenido.

Editar: es posible desactivar (= piratear) el mecanismo de generación de informes de error incorporado en Windows, por lo que el diálogo obligatorio de "bloqueo y grabación" no aparece cuando la aplicación falla. Sin embargo, esto se aplica a todas las aplicaciones del sistema, no solo a las suyas.

Respondida el 04/08/2008 a las 11:20
fuente por usuario

votos
3

¿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 la segunda publicación de blog a la que hizo referencia :

Por cierto, en mi máquina 1.1 el ejemplo de MSDN tiene el resultado esperado; es solo que la segunda línea no aparece hasta después de haber adjuntado un depurador (o no). En v2 hemos cambiado las cosas para que el evento UnhandledException se active antes de que se adjunte el depurador, que parece ser lo que la mayoría de la gente espera.

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

Respondida el 04/08/2008 a las 03:45
fuente por usuario

votos
1

Es una aplicación de Windows Forms. Las excepciones detectadas por Application.ThreadException funcionan bien, y no obtengo el desagradable cuadro .NET de excepción ( OKpara terminar, Cancelpara depurar, ¿a quién se le ocurrió eso?).

Obtuve algunas excepciones que no fueron detectadas por eso y terminé yendo al evento AppDomain.UnhandledException que causaba problemas. Creo que capté la mayoría de esas excepciones, y ahora las mostraré en nuestro bonito cuadro de error.

Así que tendré que esperar que no haya otras circunstancias que hagan que las excepciones no sean detectadas por el controlador Application.ThreadException.

Respondida el 04/08/2008 a las 03:54
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more