+1 on getting rid of IO conditions. I'd be okay with a Result based API. If we change it over, we should have a tutorial that goes over how to deal with Results to make it less painful for people (e.g. using or_return! macros).
I'm not a huge fan of implementing Reader for Result<Reader, ~Error>, etc. One thing that I've tried that I kind of like is having separate `foo` and `try_foo` methods, where `try_foo` returns a Result and `foo` is a wrapper around `try_foo` that fails with a good error message if `foo` returned Err. It makes it more explicit to users of the API what's going to happen, and when failure will occur if there's an error. A failed Result<T, ~Error> can hang around for a long time before any methods are called on it. It can also allow for slightly better failure messages. For example, if `prepare` fails, its error message can print the query string without having to copy it into a new ~str. In the IO case, you could keep this cost free to implement by having `Reader` contain a default implementation for `read` and only require users to implement `try_read`. See http://docs.octayn.net/postgres/struct.PostgresConnection.html for some examples. Steven Fackler On Wed, Oct 16, 2013 at 11:20 AM, Kevin Ballard <ke...@sb.org> wrote: > +1 here too. I agree with what Alex said about conditions. They're useful > for when you can actually recover from the error gracefully, but for > generic error reporting they're kind of a PITA. > > -Kevin > > On Oct 16, 2013, at 11:16 AM, Patrick Walton <pwal...@mozilla.com> wrote: > > > On 10/16/13 11:02 AM, Alex Crichton wrote: > >> All that being said, we're not making much progress without an idea of > where to > >> possibly go next. Right now, the current idea is to create an Error > trait and > >> have I/O operations return Result<T, ~Error> instead of Option<T>. This > would > >> mean that Reader/Writer and other associated traits would be defined for > >> Result<T, ~Error> where T: Trait (so you could still chain operations > easily), > >> and you could very easily check for an I/O error. > > > > +1 for the use of Result. Yay monads! > > > > Patrick > > > > _______________________________________________ > > 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
