This is an interesting case. I do understand your point, it is more
strict, but I'd like to advocate the other path.
Here's for example a very common pattern in real life code I'd say:
----------
d.addCallbacks(doSomething, logError);
---------
If no undefined piping, the above will stop possible further "real"
error handling.
My experience with people (myself included..) using the Deferred API
in MochiKit is that they don't expect code like the above to transform
an errback into a success-callback.
I think the overhead of having to do an explicit return to close an
errback is less than the overhead and risk of closing and hiding
errors by forgetting to pipe the input.
Initially I tried couple of helper methods that would simply wrap the
attached function in a pipe-through etc, but finally I decided, partly
based on Dojo and Closure lead, to patch MochiKit Async to propagate
values.
(See my MochiKit fork here:
https://github.com/blq/mochikit/commit/577477c888c13394b9f893bcec90320e50b845a2#diff-0
)
Secondly, I think the case of keeping an error object reference is
more of a hypothetical issue. Very rarely have I seen any particularly
heavy objects being passed as errors. I.e it should not be a case
mandating optimization on the level of API or behavior changes (side
note: optimizations for callbacks/errbacks and heavy return values
should rather be some kind of lazy callback pattern for example).
Fundamentally though I guess it's a case of overlapping logic and use-
case for a single function, listening and _re_acting on the result of
an operation is different than intending to participate in the
handling and processing of the result.
Will be interesting to hear other opinions
// Fredrik Blomqvist