Bug en el método File.ReadLines (..) de .NET Framework 4.0

Question

este código:

IEnumerable<string> lines = File.ReadLines("file path"); 
foreach (var line in lines) 
{ 
    Console.WriteLine(line); 
} 
foreach (var line in lines) 
{ 
    Console.WriteLine(line); 
} 

lanza una ObjectDisposedException : {"Cannot read from a closed TextReader."} si se ejecuta la segunda foreach. Parece que el objeto iterador devuelto desde File.ReadLines(..) no se puede enumerar más de una vez. Debe obtener un nuevo objeto iterador llamando al File.ReadLines(..) y luego usarlo para iterar.

Si sustituyo File.ReadLines(..) con mi versión (parámetros no se verifican, es sólo un ejemplo):

public static IEnumerable<string> MyReadLines(string path) 
{ 
    using (var stream = new TextReader(path)) 
    { 
     string line; 
     while ((line = stream.ReadLine()) != null) 
     { 
      yield return line; 
     } 
    } 
} 

es posible repetir más de una vez las líneas del archivo.

Una investigación que utiliza .Net Reflector mostró que la implementación de File.ReadLines(..) llama a un File.InternalReadLines(TextReader reader) privado que crea el iterador real. El lector pasó como un parámetro se utiliza en el método MoveNext() del iterador para obtener las líneas del archivo y se elimina cuando llegamos al final del archivo. Esto significa que una vez que MoveNext() devuelve falso no hay forma de iterar una segunda vez porque el lector está cerrado y debe obtener un nuevo lector creando un nuevo iterador con el método ReadLines(..).En mi versión, se crea un nuevo lector en el MoveNext() método cada vez que comenzamos una nueva iteración.

¿Es este el comportamiento esperado del método File.ReadLines(..)?

Me parece preocupante el hecho de que es necesario llamar al método cada vez antes de enumerar los resultados. También debería llamar al método cada vez antes de repetir los resultados de una consulta de Linq que utiliza el método.

Answer 1

No creo que sea un error, y no creo que sea inusual; de hecho, eso es lo que esperaría de algo así como un lector de archivos de texto. IO es una operación costosa, por lo que en general desea hacer todo en una sola pasada.

Answer 2

Si necesita acceder a las líneas dos veces siempre se pueden proteger ellos en un List<T>

using System.Linq; 

List<string> lines = File.ReadLines("file path").ToList(); 
foreach (var line in lines) 
{ 
    Console.WriteLine(line); 
} 
foreach (var line in lines) 
{ 
    Console.WriteLine(line); 
} 

Answer 3

No es un error. Pero creo que puedes usar ReadAllLines() para hacer lo que quieras en su lugar. ReadAllLines crea una matriz de cadenas y extrae todas las líneas en la matriz, en lugar de simplemente un enumerador sobre una secuencia como lo hace ReadLines.

Answer 4

No sé si puede ser considerado como un error o no si es por diseño, pero sin duda puedo decir dos cosas ...

1. Esto debe ser publicado en Connect, no Stackoverflow aunque' No vamos a cambiarlo antes de que se lance 4.0. Y eso generalmente significa que nunca lo arreglarán.
2. El diseño del método ciertamente parece ser defectuoso.

Tiene razón al señalar que devolver un IEnumerable implica que debe ser reutilizable y no garantiza los mismos resultados si se repite dos veces. Si hubiera devuelto un IEnumerator en su lugar, entonces sería una historia diferente.

De todos modos, creo que es un buen hallazgo y creo que la API es mala para empezar.ReadAllLines y ReadAllText le brindan una forma cómoda y conveniente de obtener todo el archivo, pero si la persona que llama se preocupa lo suficiente por el rendimiento como para usar un enumerable perezoso, no deberían delegar tanta responsabilidad en un método de ayuda estático en primer lugar.

Answer 5

Creo que está confundiendo un IQueryable con un IEnumerable. Sí, es cierto que IQueryable se puede tratar como IEnumerable, pero no son exactamente lo mismo. Una consulta de IQueryable cada vez que se usa, mientras que un IEnumerable no tiene dicha reutilización implícita.

Una consulta de Linq devuelve un IQueryable. ReadLines devuelve un IEnumerable.

Aquí hay una distinción sutil debido a la forma en que se crea un Enumerator. Un IQueryable crea un IEnumerator cuando se llama a GetEnumerator() en él (lo cual se hace automáticamente por foreach). ReadLines() crea el IEnumerator cuando se llama a la función ReadLines(). Como tal, cuando reutilizas un IQueryable, crea un nuevo IEnumerator cuando lo reutilizas, pero como ReadLines() crea el IEnumerator (y no un IQueryable), la única forma de obtener un nuevo IEnumerator es llamar a ReadLines() nuevamente .

En otras palabras, solo debería poder esperar volver a utilizar un IQueryable, no un IEnumerator.

EDIT:

En una reflexión más profunda (sin doble sentido) Creo que mi respuesta inicial fue un poco demasiado simplista. Si IEnumerable no era reutilizable, no se podía hacer algo como esto:

List<int> li = new List<int>() {1, 2, 3, 4}; 

IEnumerable<int> iei = li; 

foreach (var i in iei) { Console.WriteLine(i); } 
foreach (var i in iei) { Console.WriteLine(i); } 

Claramente, no se esperaría que la segunda foreach falle.

El problema, como suele ser el caso con este tipo de abstracciones, es que no todo encaja perfectamente. Por ejemplo, los flujos suelen ser unidireccionales, pero para el uso de la red debían adaptarse para funcionar bidireccionalmente.

En este caso, un dispositivo IEnumerable se concibió originalmente como una función reutilizable, pero desde entonces se ha adaptado para que sea tan genérico que la reutilización no sea una garantía o incluso esperada. Sea testigo de la explosión de varias bibliotecas que usan IEnumerables de maneras no reutilizables, como la biblioteca Jeffery Richters PowerThreading.

Simplemente no creo que podamos suponer que los documentos de IEnumerables son reutilizables en todos los casos.

Answer 6

No es un error. File.ReadLines() utiliza evaluación diferida y no es idempotent. Es por eso que no es seguro enumerarlo dos veces seguidas. Recuerde que IEnumerable representa una fuente de datos que se puede enumerar, no indica que es seguro enumerarla dos veces, aunque esto podría ser inesperado ya que la mayoría de la gente está acostumbrada a usar IEnumerable sobre colecciones idempotentes.

Desde el MSDN:

Los readlines (String, System) y ReadAllLines (String, Sistema) Métodos difieren de la siguiente manera: Cuando se utiliza readlines, puede empezar a enumerar la colección de cadenas antes de que se devuelva la colección completa ; Cuando se ReadAllLines uso, deberá esperar a que toda la matriz de cadenas ser devuelto antes de poder acceder al array.Therefore, cuando se está trabajando con archivos muy grandes, pueden readlines ser más eficiente.

Sus hallazgos a través del reflector son correctos y verifique este comportamiento. La implementación que proporcionó evita este comportamiento inesperado pero aún utiliza la evaluación perezosa.

Answer 7

Sé que esto es viejo, pero en realidad me encontré con esto mientras trabajaba en algún código en una máquina con Windows 7. Contrariamente a lo que decía la gente aquí, esto realmente era un error. Ver this link.

Así que la solución más fácil es actualizar su .net framefork. Pensé que valía la pena actualizar ya que este fue el resultado de búsqueda superior.