What about using Result types as mentioned here, but introducing some
syntactic sugar to make chaining them easier? Something like Haskell's or
Scala's "do" syntax:
do (
a <- x // x and y are Results
b <- y
) { /* do stuff with 'a' and 'b' */ }
else {
/* First Err is returned. Handle here. */
}
--
Ziad
On Thu, Oct 17, 2013 at 9:40 PM, Igor Bukanov <[email protected]> wrote:
> So the Go style is to call a function, check if the was an error,
> update the error object (or create a new wrapping the old one) with
> extra information relevant to the current call stack frame and
> propagate the updated error object to the caller. If done
> consistently, this could indeed provide very-user friendly error
> messages. But it does clutter the code with if checks and does not
> allow to recover so multiple errors could not be reported.
>
> In the above example the developer, before calling a parser library,
> may want to say that IO errors should be recovered from, so they could
> be reported together with other problems like syntax violations. I do
> not see how the Go style could be adopted to that. In its design the
> caller cannot influence the error propagation paths in the callee and
> its stack subframes.
>
> On 18 October 2013 05:29, Steven Blenkinsop <[email protected]> wrote:
> > On Thursday, October 17, 2013, Igor Bukanov wrote:
> >>
> >>
> >> Go - I have not used the language, but my general impression is that
> >> no error will be generated. Instead the file will be read as an empty
> >> string.
> >
> >
> > Go encodes the error as a value which can be either treated as a string
> or
> > programmatically inspected to determine the correct response and returns
> it
> > along with an invalid file handle. If the code doesn't actually
> specifically
> > handle permission problems, it will usually create a new error value
> > embedding the original error along with some context about what it was
> doing
> > when it got the error. This new error can then be used as a failure
> value or
> > passed up the stack, or it may be logged (potentially in combination with
> > one of the other two options). This means that, even if the developer
> didn't
> > anticipate permissions issues, the error will likely contain all the
> > relevant information, such as what line of the configuration file was
> being
> > processed as well as what file failed to open and why.
> _______________________________________________
> 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
