returns - param name c#

Destructor: ¿se llama si la aplicación falla?

Question

¿Se llama a un destructor si la aplicación falla? Si se trata de una excepción no controlada, supongo que sí, pero ¿qué pasa con los errores más graves, o algo así como que un usuario esté matando el proceso de solicitud?

Y algunas más preguntas potencialmente tontas:

• ¿Qué sucede con todos los objetos en una aplicación cuando la aplicación sale y todos los finalizadores se han ejecutado? ¿Los objetos se recolectan en la basura o están "descargados" de alguna manera con el proceso o dominio de aplicaciones?
• ¿El recolector de basura es parte de cada aplicación (se ejecuta en el mismo proceso) o es independiente?

Answer 1

Ni siquiera sé C #, pero en base a mis experiencias con otros lenguajes de programación, supongo: si una aplicación falla, significa que hay algo muy mal. Manejo de memoria incorrecto, etc. Sería extraño que cualquier lenguaje de programación intente ejecutar destructores / desasignadores / finalizadores / ... en tal caso. Las cosas probablemente irían más mal;)

Actualización: (se olvidó de intentar responder a sus otras preguntas) nuevamente, no es específico de C #, pero normalmente no hay garantía de que los destructores / desalojadores / finalizadores / ... realmente sean llamados. La razón de esto es que cuando un proceso se cierra, es mucho más fácil y más eficiente simplemente "modificar" el bloque de memoria utilizado para el proceso que ejecutar sus destructores, etc., para limpiar la memoria.

No estoy seguro de cómo responder a su última pregunta sin entrar en demasiados detalles técnicos. Hay varias formas en que los recolectores de basura se pueden diseñar y hacer que funcionen, la más fácil es que la recolección de basura detenga el proceso actual y lo continúe cuando se hace, aunque también es posible (pero más difícil) tener recolectores de basura que se ejecutan simultáneamente Con procesos cuya memoria están recogiendo.

Es posible que desee leer sobre la teoría de la recolección de basura para comprender mejor todo esto. En realidad, hay un sitio completo sobre este tema: www.memorymanagement.org .

Answer 2

Si se matara una aplicación, la aplicación perdería el control casi al 100% de inmediato y no hay posibilidad de que llame al destructor.

Answer 3

Te animo a que pruebes esto por ti mismo. Por ejemplo:

using System;

class Program {
  static void Main(string[] args) {
    var t = new Test();
    throw new Exception("kaboom");
  }
}
class Test {
  ~Test() { Console.WriteLine("finalizer called"); }
}

Ejecuta esto en el símbolo del sistema para que puedas ver el último jadeo. Primero con la declaración de lanzamiento comentada.

Al igual que cualquier excepción no controlada en Windows, el filtro de excepción predeterminado que Windows proporciona invoca el cuadro de diálogo Informe de errores de Windows, que se muestra en WerFault.exe. Si hace clic en "Cerrar programa", WerFault usará TerminateProcess () para finalizar el programa. Eso es un final rápido, no hay oportunidad de ejecutar el subproceso finalizador, como sucedería cuando un programa sale normalmente.

Windows luego se encarga de limpiar la metralla. Puede cerrar automáticamente cualquier manija del sistema operativo que su programa pudo haber abierto pero no tuvo la oportunidad de cerrar en el finalizador. Los archivos son el problema más complicado aquí, sus buffers no se vacían y terminará fácilmente con un archivo parcialmente escrito en el disco.