On 30 May 2015 at 1:26, Peter Dimov wrote:
It's not that I don't like it, I don't see sufficient motivation for it.
Actually I've changed my mind and now I don't like it. It's a catch(...) without a rethrow, and while those are occasionally necessary, they are not likable.
To be clear, I'm talking about the N4048's .catch_error that takes an exception_ptr, not an error_code.
I am sympathetic to this line of thought. Once you allow an error_code, it becomes hard to imagine where treating exception_ptr outcomes as just another value returned can be wise. Ok, so if .next() filters for T, would .next_error() filter for error_code? I can't say I like the name .next_error(). It suggests "the next error", not the current one. .on_error() maybe? But then .next() should be .on_value() instead right?
I'm also not quite sure how it's to be used. Vicente's wording in N4048 is a bit unclear.
future<X> f1 = async( ... ); future<Y> f2 = f1.catch_error( []( exception_ptr e ) { return Y(); } );
What happens when f1 has a value?
Surely for catch_error() one must always return the same type of future as the input? Otherwise it couldn't work when f1 has a value.
Vicente in N4048 says that it's not required to return the same type.
Oh. I don't know how that can work then. Maybe Vicente can clarify? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/