From: Emil DotchevskiSent: Freitag, 14. Juli 2017 18:37 To: boost@lists.boost.org
Ah, now I get it, thanks for the explanation. There *might* even be a way to get this to work even without memory allocation in the end (without exception_ptr), but I think this is perhaps missing the point of returning an error object, which is to be able to interact with it. Also, reasonably if you could fit the things you need to create the object into a "small object optimized" buffer, you can probably fit the object itself into the same buffer. Noexcept already has that, it's the result<T> object, however it might be too heavy to return up the call chain one level at a time (it is instead designed for capturing the TLS- stored object to postpone its handling, perhaps after moving it to another thread).
The question is: how do you interact with a return value of unknown type? For exceptions it's much easier. There is at least the common practice to derive your exception from std::exception, so if nothing else, you can at least get an error message. And you can catch base classes, which can also come in quite handy.
On Sat, Jul 15, 2017 at 2:23 PM, Groke, Paul via Boost < boost@lists.boost.org> wrote:
From: Emil DotchevskiSent: Freitag, 14. Juli 2017 18:37 To: boost@lists.boost.org
Ah, now I get it, thanks for the explanation. There *might* even be a way to get this to work even without memory allocation in the end (without exception_ptr), but I think this is perhaps missing the point of returning an error object, which is to be able to interact with it. Also, reasonably if you could fit the things you need to create the object into a "small object optimized" buffer, you can probably fit the object itself into the same buffer. Noexcept already has that, it's the result<T> object, however it might be too heavy to return up the call chain one level at a time (it is instead designed for capturing the TLS- stored object to postpone its handling, perhaps after moving it to another thread).
The question is: how do you interact with a return value of unknown type? For exceptions it's much easier. There is at least the common practice to derive your exception from std::exception, so if nothing else, you can at least get an error message. And you can catch base classes, which can also come in quite handy.
It works exactly the same with Noexcept: if you use throw_, the object can always be intercepted as either std::exception or boost::exception, the former is useful in the case you need to handle an error no matter its type, the latter if you want to augment the error object with contextual data before passing the error up the call chain.
2017-07-15 23:23 GMT+02:00 Groke, Paul via Boost <boost@lists.boost.org>:
From: Emil DotchevskiSent: Freitag, 14. Juli 2017 18:37 To: boost@lists.boost.org
Ah, now I get it, thanks for the explanation. There *might* even be a way to get this to work even without memory allocation in the end (without exception_ptr), but I think this is perhaps missing the point of returning an error object, which is to be able to interact with it. Also, reasonably if you could fit the things you need to create the object into a "small object optimized" buffer, you can probably fit the object itself into the same buffer. Noexcept already has that, it's the result<T> object, however it might be too heavy to return up the call chain one level at a time (it is instead designed for capturing the TLS- stored object to postpone its handling, perhaps after moving it to another thread).
The question is: how do you interact with a return value of unknown type? For exceptions it's much easier. There is at least the common practice to derive your exception from std::exception, so if nothing else, you can at least get an error message. And you can catch base classes, which can also come in quite handy.
I think this can be done through Boost.TypeErasure. You can type erased almost anything (almost like Boost.Any), subject to constraint that it has to have member function `what()`. Then, you can query the erased object for the type you are interested in handling. Regards, &rzej;
participants (3)
-
Andrzej Krzemienski -
Emil Dotchevski -
Groke, Paul