You make a good case that it happens less in Go, but I'm still not sold on Go's
error handling, given that it's fundamentally built on a model that's known to
be error-prone. We know that the flaw of error-code-based systems without
checked returns is that you can forget to handle errors. Go makes this harder
in many situations, but it has known holes when the function returns nothing
but an error or the function is invoked only for its side effects. I don't see
any reason why we should deliberately go with a system with known flaws and
failure modes when there are better alternatives available.
In other words: Why bet, as Go did, that the failure case won't happen much in
practice when we can adopt an error-handling strategy that rules it out
entirely?
Florian Weimer <[email protected]> wrote:
>* Patrick Walton:
>
>> On the other hand, Cindy Rubio-González's work shows that in the
>Linux
>> kernel, forgetting to handle error codes is *extremely* common.
>>
>> http://www.eecs.berkeley.edu/~rubio/
>>
>> I don't see anything fundamentally different with Go's approach that
>> will lead to a different outcome.
>
>The kernel usually passes results by storing them in an existing
>object because allocation by the callee is less efficient and
>impossible in many contexts. Go has garbage collection, and returning
>a new object and an error return value is the more common style. The
>result-plus-error case has a much better chance of being handled
>correctly.
>
>Go also has exceptions (for signaling certain errors). I'm not sure
>if it deals with memory allocation failures gracefully. If it
>doesn't, that would eliminate a fair chunk of kernel error handling,
>too.
>
>So in short, Go is quite different. :-)
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
