3 ms·

You and I sound like we may be cut from similar cloth. I find Go's approach to error handling -- which is to not to do much about the problem at all -- is bett

by fdr 14y ago

You and I sound like we may be cut from similar cloth. I find Go's approach to error handling -- which is to not to do much about the problem at all -- is better than pervasive use of exceptions but worse than some other possible mechanisms (and on this we may disagree). Although I'm not saying the language Rust has got it right, perhaps some of the thoughts on the mailing list may be useful. However scarily, my mailing list post -- which only asks how to handle errors -- still ranks on top for "rust error handling" on Google: https://mail.mozilla.org/pipermail/rust-dev/2012-March/001454.html https://mail.mozilla.org/pipermail/rust-dev/2012-March/00145... Here I mention the Common Lisp condition system, which has been my favorite so far, but the one of the principal authors of Rust mention a somewhat similar but lighter weight alternative.

pcwalton 14y ago
We're interested in adding support for condition handlers. Arbitrary stack unwinding and/or first-class continuations aren't likely due to runtime/toolchain limitations, but the "register a function to be called on error, which might direct the call to be restarted" style is intended to be supported.
rogerbinns 14y ago
I actually prefer exceptions to Go's approach, mainly because most of my code is structured with the best place to handle errors being higher up the call chain. Exceptions let me do that for free, whereas Go requires boilerplate code all over the call chain. BTW your posting left out that close() can also fail (eg deferred writes run out of disk space). And note that none of these really help with testing. In your 'cat' example, I'd want to test open failing, read failing, write failing and close failing. At a certain level the combination of language and libraries know these can fail. Ideally I would like to write zero lines of code to exercise those cases. In practise I usually find out that my test code is larger than the code being tested, and I usually have to add all sorts of instrumentation to force various failure modes which again makes my original code even longer and more obfuscated.
- PuerkitoBio 14y ago
  Go's panic/recover pattern lets you handle exceptions in the place you feel is best, much like exceptions. Though it is true that you would still need to check the error returned, and panic if not nil. However, there are a few libraries that offer 2 versions of the same functions, one that returns the value and error combo, and one that panics in case of error and returns only the value (regexp' Compile and MustCompile for example). When it makes sense, it's nice to have this option. Anyway, error handling is hard, I'm not a fan of exceptions, though alternatives such as Node's error as first argument of a callback and Go's second return value require polluting the normal code path. I like go's "defer" idea as a "finally", though.

by fdr 14y ago

pcwalton 14y ago

We're interested in adding support for condition handlers. Arbitrary stack unwinding and/or first-class continuations aren't likely due to runtime/toolchain limitations, but the "register a function to be called on error, which might direct the call to be restarted" style is intended to be supported.

rogerbinns 14y ago

I actually prefer exceptions to Go's approach, mainly because most of my code is structured with the best place to handle errors being higher up the call chain. Exceptions let me do that for free, whereas Go requires boilerplate code all over the call chain. BTW your posting left out that close() can also fail (eg deferred writes run out of disk space). And note that none of these really help with testing. In your 'cat' example, I'd want to test open failing, read failing, write failing and close failing. At a certain level the combination of language and libraries know these can fail. Ideally I would like to write zero lines of code to exercise those cases. In practise I usually find out that my test code is larger than the code being tested, and I usually have to add all sorts of instrumentation to force various failure modes which again makes my original code even longer and more obfuscated.

PuerkitoBio 14y ago
Go's panic/recover pattern lets you handle exceptions in the place you feel is best, much like exceptions. Though it is true that you would still need to check the error returned, and panic if not nil. However, there are a few libraries that offer 2 versions of the same functions, one that returns the value and error combo, and one that panics in case of error and returns only the value (regexp' Compile and MustCompile for example). When it makes sense, it's nice to have this option. Anyway, error handling is hard, I'm not a fan of exceptions, though alternatives such as Node's error as first argument of a callback and Go's second return value require polluting the normal code path. I like go's "defer" idea as a "finally", though.