Perhaps it would help if we actually had a static io::EOF
static EOF: IoError = IoError { kind: EndOfFile, desc: "end of file", detail:
None }
Then we could use this in match patterns as in
match w.write(buf) {
Err(EOF) => handle_eof(),
Err(e) => handle_other_error(),
Ok(n) => ...
}
-Kevin
On Feb 4, 2014, at 3:15 AM, Matthias Einwag <[email protected]>
wrote:
> 0 is no necessarily EOF.
> E.g. it's not EOF
> - when you requested to read 0 bytes, which is perfectly legal
> - when your IO Object is in nonblocking mode (yes, that's currently not
> supported in Rust, but might be in Future)
>
> And the Result<Option<int>, IoError> will only create questions when the the
> Err Result will be used as opposed to the None Option. I don't know if you
> would associate an Ok(None) with an EOF if you first-time encounter it.
>
> Therefore I think the current Err(EOF) is absolutely fine.
>
>
> 2014-02-04 Bill Myers <[email protected]>:
> Are we sure that this is the correct design, as opposed to having read return
> 0 for EoF or perhaps returning None with a Result<Option<int>, IoError>
> return type?
>
> After all, EOF is unlike all other I/O errors, since it is guaranteed to
> happen on all readers, and the fact that it needs to be special cased might
> be an indication that the design is wrong.
>
> Also, in addition to "raw" eof, a partial read due to end of file causes the
> same issues, so it seems that code needs to have two match conditions to
> handle eof, while it would only need a single one if eof was represented by
> Ok(0).
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
