¿Por qué no debería usar Process.GetCurrentProcess(). Kill() para salir de mi aplicación WinForm?

Question

En este momento, cuando el usuario quiere salir de mi solicitud, hago las pocas cosas que tengo que (es decir, de desconectarse del servidor, guardar los datos de usuario ...) y luego hago lo siguiente:

• Salir de todos mis mainloops usando booleans
• abortar los hilos aún en ejecución (generalmente, el hilo de sondeo de mi servidor)
• amablemente llame a Application.Exit();

Esta toma unos segundos para salir, y no sirve a ningún propósito real (todo lo que ya se guarda en el servidor, por lo que no les importa lo que sucede allí)

Si utilizo este lugar, me consiguió la terminación inmediata sin inconveniente que puedo pensar:

System.Diagnostics.Process.GetCurrentProcess().Kill(); 

Por qué no me acabo de terminar mi proceso y dejar que el CLR caer el dominio de aplicación?

Sé que es importante deshacerse cuidadosamente de sus recursos compartidos (manejadores de archivos IO, etc.) (así que no responda :)), pero una vez hecho, ¿hay alguna razón real para salir limpiamente de mi aplicación?

Answer 1

En primer lugar, creo que quiere decir Process.Kill(), no Process.TerminateProcess(). En segundo lugar, matar el proceso simplemente lo destruirá. Cualquier código de limpieza no se ejecutará y su aplicación no tendrá la posibilidad de cancelar la ejecución (por ejemplo, si el usuario tiene datos no guardados). Si estás contento con eso, ve por ello.

Answer 2

¡Esa es una buena pregunta!

Érase una vez (hace más de diez años) escribí una aplicación VB6 que se colgó en la terminación debido a un error confirmado en WinINet OCX (o como se llame) debido al certificado particular utilizado en un servidor web estaba hablando con.

Sin ninguna forma de solucionar este error utilicé TerminateProcess y, por lo que sé, esta aplicación estuvo en uso en varios miles de máquinas durante varios años y nunca escuché ningún problema con respecto a este truco.

Answer 3

Tenga en cuenta que si está escribiendo en una secuencia de archivo/red es posible que su escritura sea incompleta.

Si su aplicación está lista para tratar datos corruptos de esa manera, entonces no hay razón para no hacerlo. Sin embargo, si puede salir por otros medios, lo recomendaría.

Answer 4

Al matar el proceso, significa que finalmente no se ejecutarán los bloques, y probablemente ni siquiera critical finalizer objects, lo que en realidad puede ser crítico y puede causar la fuga de recursos a nivel del sistema. También puede causar errores inesperados en el futuro cuando otra persona mantiene el código, ya que ellos (o usted) tendrán que retorcer sus cabezas, teniendo que pensar que cada vez que escriban un bloque finalmente, se lo ejecutará.

Answer 5

¿Por qué no utilizar System.Environment.Exit(int)? Parece que quieres hacer esto solo para guardar el código. Para mí, es mucho más claro ver que la llamada a Exit lo hace y tu apagado será más controlado, se ejecutarán Finalizers y Finalizers críticos.

Answer 6

Cabe señalar que finalizers may actually be never executed, por lo que matar el proceso no es muy diferente de cualquier otra razón para omitir el código de finalización, como finalizadores lentos o un finalizador lanzando una excepción.

En general, no me preocuparía demasiado cerrar la aplicación en unos segundos, especialmente si oculta inmediatamente todas sus ventanas y "desaparece" para el usuario. Sin embargo, si el cierre demora decenas de segundos y es probable que el usuario ejecute la aplicación de nuevo y no es compatible con varias instancias, puede ser una buena idea llamar al Process.Kill.

Sé que algunas aplicaciones que tienen edades a finalizar, y espero ver algún día acaba matando brutalmente a sí mismos en lugar de hacer yo, el usuario, lo hacen (que es especialmente molesto en el reinicio del sistema operativo).

Answer 7

Utilizando bibliotecas de terceros sin forma de detectar sus errores o fugas, a veces la única forma de finalizarlo sin lanzar un MessageBox de error es matar el proceso.