On 19/02/14 21:44, Kevin Ballard wrote:
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.

Yes, Python, at least, raises exceptions - IOError and OSError, specifically.

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".

It sounds like a very specific way to handle a very general problem. People like (modern, complete) scripting languages because they handle this sort of intricacy in elegant, ways, not because they gloss over it and make half-baked programs that don't handle errors. It's just that you can, say, handle IOErrors in one step, at the top of your script, except for one particular issue that you know how to recover from, six levels into the call stack. Exceptions (so long as there isn't a lot of boilerplate around them) let you do that, easily. Rust needs a similarly generic approach to propagating errors and handling them five levels up, whether that's exceptions or fails (I don't think they currently are flexible enough), or monads, or something else.

That said, I'm comfortable with things as they are now.

I'm not. I think this is the tip of the iceberg: a code smell that's tipping us off about deeper usability issues.

Making .lines() provide an IoResult would destroy much of the convenience of the function.

Only if there's no convenient way to handle ioResults (or results in general).

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.

a) It's a file handle, which can be mapped to a pipe, a serial port, or some other much more error prone input device than the terminal b) It may be stdin, but it's also the input to your program. Garbage in, garbage out. c) Ideally your code won't care if it's stdin or some other device, except for a few lines of code which check the configuration / environment and decide which input file to pass to other code.



--
Lee

_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to