Hi, I trying to implement Andrei's Expected<T> from his "Systematic Error Handling in C++" talk ( http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandre...) in C++03 / BOOST In short: Expected<T> holds either T or exception_ptr holding exception that prevented T's creation. Think of single threaded future<T>. One of main purposes of this type is efficiency - code that computes T would normally throw in case of errors but instead it returns exception by value which causes Expected<T> to be initiated with exception type instead of actual value of T. Important part is that no throwing happens in library code (making it fast). As with future<T> throwing of stored exception only happens upon client's request - a call to get() in case of invalid computation (Expected<T>::valid() may be called beforehand to check if computation succeeded). To the point: Andrei's code uses std::make_exception_ptr() which I assume is std version of boost::copy_exception(). Now problem with copy_exception() is that it actually throws! So the whole idea of not throwing is gone by the fact that I don't know how to transform (const Exception&) into boost::exception_ptr (without throwing via copy_exception()). How does std::make_exception_ptr() work (as I assume it does not throw & return current_exception() as boost::copy_exception does)? Any suggestions welcome. Cheers. Szymon Gatner
On 12.12.2012, at 16:14, Szymon Gatner wrote:
Hi,
How does std::make_exception_ptr() work (as I assume it does not throw & return current_exception() as boost::copy_exception does)? Any suggestions welcome.
By using compiler-specific knowledge of how the exception system works. Or the same way as boost::copy_exception, like GCC's implementation. IOW, it does throw. Sebastian
2012/12/12 Sebastian Redl
By using compiler-specific knowledge of how the exception system works. Or the same way as boost::copy_exception, like GCC's implementation. IOW, it does throw.
Thanks for clarification. This means that Andrei's version might in practice not be faster at all as non-exceptional path might not be so non-exceptional afterall. Still, it is perfect thing for async callback-based APIs when throwing penalty is OK and client code wants to handle computation exception. Cheers, Simon
On Wed, Dec 12, 2012 at 7:14 AM, Szymon Gatner
Important part is that no throwing happens in library code (making it fast).
Throwing doesn't have to be fast because by definition it is used to handle an exceptional situation. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (3)
-
Emil Dotchevski
-
Sebastian Redl
-
Szymon Gatner