Destructores, disposes y otras yerbas.

26/04/2006 - 22:07 por solved by design | Informe spam
A ver si alguien me puede aclarar esto.

class Log
{
private StreamWriter sw;
public Log() {sw=new StreamWriter("log.txt");}
public Write(string s) {sw.WriteLine(s);}
~Log() {sw.WriteLine("FIN LOG");sw.Close();}
}

La clase es, evidentemente, mucho más compleja, pero este esqueleto sirve.

Básicamente, el problema consiste en que a la hora de ser llamado el
destructor, el StreamWriter ha sido cerrado.

Me le releído como 10 veces todo el tema de los IDisposable, etc, y de hecho
la he ampliado con el interface IDisposable y he implementado un interface
Dispose() público y otro protegido y virtual (Dispose(bool) ), siguiendo el
ejemplo, pero dentro de cualquier dispose o del destructor, el sw ya ha sido
cerrado.

¿Dónde la cago?

Gracias de antemano.

Amo a la Humanidad, lo que me revienta es la gente.
Mafalda.

Preguntas similare

Leer las respuestas

#1 Alberto Poblacion
26/04/2006 - 22:22 | Informe spam
"solved by design" wrote in message
news:eTP$
[...]
Básicamente, el problema consiste en que a la hora de ser llamado el
destructor, el StreamWriter ha sido cerrado.



El problema es que, a diferencia de otros lenguajes tradicionales, en C#
el orden de llamada de los destructores no es determinista. Cuando un objeto
se convierte en inalcanzable no se ejecuta su destructor. Hay que esperar a
que pegue una pasada el Garbage Collector, que libera la memoria de los
objetos que le convenga (no necesariamente todos los que se podrían
liberar), a no ser que tengan un destructor, en cuyo caso los envía a la
cola de destrucción. Sobre esa cola se ejecuta un hilo separado que va
ejecutando los destructores de los distintos objetos que haya en la cola.
Debido a este mecanismo, no se garantiza ningún orden en particular para la
destrucción de los varios objetos que tengan que destruirse. Como el
StreamWriter tiene su propio destructor, y tu clase tiene otro, pues puede
ocurrir que el StreamWriter haya ejecutado su destructor antes de que se
ejecute el de tu clase.
Respuesta Responder a este mensaje
#2 solved by design
26/04/2006 - 22:53 | Informe spam
"Alberto Poblacion" wrote
in message news:
"solved by design" wrote in message
news:eTP$
[...]
Básicamente, el problema consiste en que a la hora de ser llamado el
destructor, el StreamWriter ha sido cerrado.



El problema es que, a diferencia de otros lenguajes tradicionales, en
C# el orden de llamada de los destructores no es determinista. Cuando un
objeto se convierte en inalcanzable no se ejecuta su destructor. Hay que
esperar a que pegue una pasada el Garbage Collector, que libera la memoria
de los objetos que le convenga (no necesariamente todos los que se podrían
liberar), a no ser que tengan un destructor, en cuyo caso los envía a la
cola de destrucción. Sobre esa cola se ejecuta un hilo separado que va
ejecutando los destructores de los distintos objetos que haya en la cola.
Debido a este mecanismo, no se garantiza ningún orden en particular para
la destrucción de los varios objetos que tengan que destruirse. Como el
StreamWriter tiene su propio destructor, y tu clase tiene otro, pues puede
ocurrir que el StreamWriter haya ejecutado su destructor antes de que se
ejecute el de tu clase.





Joder, y mira que siempre lo tengo en cuenta, y siempre se me pasa a la hora
de la verdad.

Entonces, una solución sería crear y destruir el StreamWriter (porque no se
puede abrir/cerrar) cada vez que quiera escribir en el fichero... Una
burrada a mi modo de ver.

La solución más factible entonces es implementar un método Close y cerrarlo
a mano igual que se hace con el propio StreamWriter, aunque no sea demasiado
POO.

Mañana probaré a heredar de StreamWriter... Me haré un "StreamLog", ji ji, a
ver si funciona.

Gracias por aclararme el tema.

Amo a la Humanidad, lo que me revienta es la gente.
Mafalda.
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida