Feature #4834
closed
NDN_THROW: improved replacement for BOOST_THROW_EXCEPTION
Added by Junxiao Shi almost 6 years ago.
Updated over 5 years ago.
Description
BOOST_THROW_EXCEPTION
is quite inflexible for our use cases. Since our exception types do not derive from boost::exception
, in order to augment the thrown exception with additional error_info
structs, each user has to wrap the constructed exception in a boost::enable_error_info
call.
I'm proposing NDN_THROW
as an improved alternative and drop-in replacement for BOOST_THROW_EXCEPTION
. Some of the improvements over its boost counterpart are:
- Easy chaining of
error_info
structs to transport arbitrary types to the catch site, e.g.:
NDN_THROW(std::runtime_error("foo")) << my_error_info("bar") << more_info(42);
- On platforms with boost >= 1.65, automatically embeds a stack trace up to the throw site, which can be inspected or printed at the catch site.
- Additional
_ERRNO
and _NESTED
variants, that automatically capture the value of errno
and the active exception (to be nested in the new exception), respectively. These two macros substantially reduce repeated boilerplate code when dealing with C library functions and nested exceptions.
- Fully compatible with
boost::diagnostic_information
and boost::current_exception
.
- Much shorter macro name :)
@Davide, please update description to explain how proposed NDN_THROW
differs from BOOST_THROW_EXCEPTION
.
- Subject changed from NDN_THROW to NDN_THROW: improved replacement for BOOST_THROW_EXCEPTION
- Description updated (diff)
- Status changed from New to In Progress
- % Done changed from 0 to 50
Is nfd::getExtendedErrorMessage
still necessary to print the error? If so, it should be included in ndn-cxx/util/exception.hpp
.
getExtendedErrorMessage
is not (and has never been) necessary. You can always catch the exception as a std::exception&
and print the .what()
message. That'll still work as usual. Or catch as boost::exception&
and use get_error_info()
to extract the details.
That being said, I recommend to get rid of getExtendedErrorMessage
and use boost::diagnostic_information
instead. It's much more powerful and supports printing all error details out of the box, including nested exceptions. If special/prettier formatting for a custom error_info
is desired, it is sufficient to define a to_string()
function for the corresponding specialization. This design also has the advantage of not requiring to change all catch sites to explicitly support each new error_info
type.
- % Done changed from 50 to 70
- % Done changed from 70 to 90
- Status changed from In Progress to Code review
- % Done changed from 90 to 100
- Status changed from Code review to Closed
Also available in: Atom
PDF