I came across this blog post which may be relevant:
https://coderwall.com/p/kokm7w
--
Ziad
On Fri, Oct 18, 2013 at 10:23 AM, Ziad Hatahet <hata...@gmail.com> wrote:
> 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 <i...@mir2.org> 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 <steven...@gmail.com> 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
>> 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
