On Apr 28, 2013, at 2:17 PM, "Pierre T."
On 04/28/2013 07:30 PM, Vicente J. Botet Escriba wrote:
Yes this is quite similar if we had exceptions and we had a try/catch block
f0().then(f1).then(f2).then(f3).visit_error(error_visitor);
try { f3(f2(f1(f0()))); } catch(...) { error_visitor(); }
When the chain gets long, try blocks make increasing sense.
It would be great if we could have the equivalent for try { h(f(), g()); } catch(...) { error_visitor(); }
when_all(f(), g()).then(h).visit_error(error_visitor);
"if_all" seems better than "when_all". [snip]
I think we could just do the following:
e.then(f, g).then(h).inspect(error_inspector)
"inspect" doesn't carry much meaning in context. [snip]
About the "inspect" method, I try to find another name instead of visit_error because it makes me think to the pattern visitor which is too specific to hierarchy classes. I found that inspect was nice because it's like in a factory where the chief "inspects" that everything has been alright.
The name should work independently of the name of the 'then()' function. Oh nice remark.
+1
on_exception? if_exception? catch_all? capture?
e.catch_all(eh);
And maybe catching/capturing an exception type at a time.
e.catch_one<E1>(e1).catch_one<E2>(e2).catch_all<EA>(eh);
e.capture<E1>(e1).capture<E2>(e2).capture<all>(eh);
But a C++ try/catch is not worst, or is it?
try { v=e.get(); } catch(E1 & ex) { e1(ex); } catch(E2 & ex) { e2(ex); } catch(...) {}
I would say "on_error", so it would be a generic name for error type that aren't exception.
"on_error" seems fine. It reminds me, however, of functions overloaded to take system_error to avoid exceptions. IOW, rather than passing a function, one passes the exception type to collect the error. ___ Rob (Sent from my portable computation engine)