On Sat, Jan 30, 2016 at 6:51 AM, Niall Douglas
On 29 Jan 2016 at 15:47, Emil Dotchevski wrote:
Obviously this is beyond the scope of std::system_error, I was just saying that really exceptions or other error-reporting objects need to be able to transport anything at all, especially in library-level code.
Something I've always wished for is for std::exception to be able to transport one or more stack backtraces. I rolled my own for AFIO v1 where it captures the stack both inside the engine and the stack where end user code called AFIO code (both were always in different threads), but it's a lot of code and is not efficient, and sadly will not be present in AFIO v2 which is 98% noexcept and single threaded throughout.
Backtraces aren't enough. It is necessary for exception objects to be able to transport arbitrary data, though of course one of the things that would make sense to transport is a stack trace. I had proposed http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3757.html, which was turned down because it was ruled that it requires a change in the (std::exception) ABI. I am pretty sure that thread local storage can be used to implement N3757 without ABI changes but I haven't got around to try to implement it. If exception objects can transport any data whatsoever, then there is no need to worry whether individual data, like system error codes, are sufficiently flexible. Emil