2011-02-14 5 views
7
using (var sw = new StreamWriter (file)) 
{ 
    XmlSerializer xs = new XmlSerializer (typeof (T)); 
    xs.Serialize (sw, data); 
    sw.Close() 
} 

sé que no tiene que llamar Dispose pero tienes que llamar al método Close en sw?Cuando usa el alcance de uso, ¿tiene que llamar a Close methods?

+2

http://stackoverflow.com/questions/1187700/does-disposing-a-streamwriter-close-the-underlying-stream – ClosureCowboy

+0

posible duplicado de [Does Stream.Dispose siempre llama a Stream.Close (y Stream.Flush) ] (http://stackoverflow.com/questions/911408/does-stream-dispose-always-call-stream-close-and-stream-flush) –

Respuesta

7

No! No es necesario. Se trata de "usar"

+0

Gracias, pero ¿cómo sabe llamar al método Close? ¿Es realmente llamado por el método Dispose? –

+0

¡sí! el método Dispose llama a Close() –

+1

@Joan Venge. Otra forma: vea la respuesta aceptada en la pregunta @ClosureCowboy vinculada a. 'using' llama al método Dispose de' IDisposable', que es lo que Close también hace. –

2

La idea detrás de IDisposable es que las clases que implementan harán lo que sea necesario para una limpieza "razonable" si se llama al método IDisposable.Dispose. La acción exacta realizada por Dispose puede variar dependiendo del estado de un objeto, y puede no ser siempre el estilo de limpieza que se desea. Por ejemplo, un objeto de comando/transacción puede realizar una reversión si se elimina sin llamar primero a un método de "confirmación". Esto restauraría el comando/transacción a un estado "seguro", pero no necesariamente el que estaba destinado.

Tenga en cuenta también que el manejo de errores puede ser diferente en casos que implican un "cierre" explícito, un "descarte" determinista o un "finalizador" no determinista (que resulta del abandono del objeto). Está claro semánticamente que una operación "cercana" que no da como resultado que el objeto cerrado esté en el estado correcto debería arrojar una excepción. No está tan claro que un método Dispose debería hacerlo. (*) Algunas clases arrojarán desde una disposición fallida y otras no. Si se abandona un objeto y se produce un problema durante la finalización, pocas clases proporcionarán una notificación, ya que no existe un buen mecanismo para solucionarlo. Si la operación "cerrar" al final de guardar un documento falla porque alguien sacó su unidad USB demasiado pronto, una aplicación puede informar al usuario que el documento puede no haberse guardado, y el usuario puede actuar en consecuencia. Si la aplicación abandona el objeto de archivo para que la operación "cerrar" no se produzca hasta un tiempo después, en cuyo momento se ha eliminado la unidad USB, no hay mucho que la aplicación pueda hacer para manejar el error. En la situación anterior, el programa podría sugerir que el usuario intente nuevamente guardar el documento, pero en esta última situación el documento podría desaparecer.

(*) Si no hay una excepción pendiente cuando ocurre un Descarte, y Dispose no puede realizar su limpieza requerida, está bastante claro que debe lanzarse una excepción. Por otro lado, si una excepción ya está pendiente, tirar desde Dispose destruirá toda la información que contenga la excepción anterior. Mi estilo preferido sería usar un método Dispose (Exception Ex) que pasará Ex como una excepción interna si el Dispose falla, pero sin el soporte de idiomas tal cosa solo puede ser soportada con una sintaxis incómoda en vb.net, y con un comportamiento dudoso. Cª#.

Cuestiones relacionadas