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

Reply via email to