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) => ...
}
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, IoError> will only create questions when the
the Err Result w
Hi,
Awesome. I have been waiting for this for a long time :D
On 04/02/2014 02:00, Alex Crichton wrote:
2. The new if_ok!() macro. This macro has a fairly simple definition
[0], and the idea is to return-early if an Err is encountered, and
otherwise unwrap the Ok value. Some sample usage looks
On 04/02/14 03:47, Bill Myers wrote:
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, IoError> return type?
After all, EOF is unlike all other I/O errors, since it is guaranteed to happen
on all readers, and the fa
On 04/02/14 03:49, Bill Myers wrote:
it is guaranteed to happen on all readers
I meant all finite readers, such as those for normal disk files.
What are you getting at here, Bill? I thought you intended the
opposite: to hint that could happen a lot on (async) infinite streams.
--
Lee
___
> it is guaranteed to happen on all readers
I meant all finite readers, such as those for normal disk files.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
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, 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 m
Cool, thanks!
-Palmer Cox
On Mon, Feb 3, 2014 at 10:36 PM, Steven Fackler wrote:
> You can also use a nested pattern:
>
> match reader.read(buf) {
> Ok(cnt) => { /* stuff */ }
> Err(IoError { kind: EndOfFile, .. } => { /* eof stuff */ }
> Err(e) => return Err(e)
> }
>
> Steven Fack
You can also use a nested pattern:
match reader.read(buf) {
Ok(cnt) => { /* stuff */ }
Err(IoError { kind: EndOfFile, .. } => { /* eof stuff */ }
Err(e) => return Err(e)
}
Steven Fackler
On Mon, Feb 3, 2014 at 10:32 PM, Alex Crichton wrote:
> I'd recommend one of two solutions, on
I'd recommend one of two solutions, one is a match guard:
match reader.read(buf) {
Ok(cnt) => { /* ... */ }
Err(ref e) if e.kind == io::EndOfFile => { /* ... */ }
Err(e) => return Err(e)
}
and the other would be to home-grow your own macro if you find
yourself writ
I like this change quite a bit. However, is there a more succinct way than
the following to take an action on EOF:
match reader.read(buff) {
Ok(cnt) => {
// Do something
}
Err(io_error) => match io_error.kind {
EndOfFile => {
// Do something for EOF
> By returning a Result from all function calls, it's not much cleaner
> to handle errors
Oops, wrong word there, I meant to indicate that it *is* much cleaner
to handle errors with Result rather than conditions.
___
Rust-dev mailing list
Rust-dev@mozill
Greetings Rustaceans!
Upon updating your nightly builds tonight some of you may realize that
all I/O code will fail to compile. Fear not, this simply means that
#11946 has landed! The summary of this change is the same as its
title, "remove io::io_error". This is quite a far-reaching change,
despi
13 matches
Mail list logo
