My understanding is that .lines() exists primarily to make quick-and-dirty I/O as easy as it is in, say, a scripting language. How do scripting languages handle I/O errors when iterating lines? Do they raise an exception? Perhaps .lines() should fail!() if it gets a non-EOF error. Then we could introduce a new struct to wrap any Reader that translates non-EOF errors into EOF specifically to let you say “I really don’t care about failure”.
That said, I’m comfortable with things as they are now. Making .lines() provide an IoResult would destroy much of the convenience of the function. I know I personally have used .lines() with stdin(), which is an area where I truly don’t care about any non-EOF error, because, heck it’s stdin. All I care about is when stdin is closed. -Kevin On Feb 19, 2014, at 9:40 AM, Palmer Cox <palmer...@gmail.com> wrote: > I think the Lines iterator could translate an EOF error into a None to abort > iteration and pass all other errors through. I don't see a WouldBlock error > code (is that the same as IoUnavailable), but that only applies to > non-blocking IO and I don't think it makes sense to use use the Lines > iterator in non-blocking mode. > > -Palmer Cox > > > > On Wed, Feb 19, 2014 at 12:35 PM, Corey Richardson <co...@octayn.net> wrote: > Keep in mind that "end of file" and "would block" are considered "errors"... > > > On Wed, Feb 19, 2014 at 12:26 PM, Palmer Cox <palmer...@gmail.com> wrote: > Why not just modify the Lines iterator to return values of IoResult<~str>? > All the caller has to do to unwrap that is to use if_ok!() or try!() on the > returned value, so, its basically just as easy to use and it means that > errors are handled consistently. I don't see why this particular use case > calls for a completely different error handling strategy than any other IO > code. > > -Palmer Cox > > > > On Wed, Feb 19, 2014 at 6:31 AM, Michael Neumann <mneum...@ntecs.de> wrote: > > Am 19.02.2014 08:52, schrieb Phil Dawes: > > Is that not a big problem for production code? I think I'd prefer the default > case to be to crash the task than deal with a logic bug. > > The existence of library functions that swallow errors makes reviewing code > and reasoning about failure cases a lot more difficult. > > This is why I proposed a FailureReader: > https://github.com/mozilla/rust/issues/12368 > > Regards, > > Michael > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
