Closed zlojvavan closed 1 year ago
It'd be more annoying to have to remove the \n
in case it isn't needed.
in it's current implementation it defaces generated diagnostic string to some extent what are those other scenarios when trailing "\n" would annoy?
This looks good to me:
example.cpp(14): Throw in function main
Dynamic exception type: boost::wrapexcept<my_error>
std::exception::what: std::exception
[my_info1_*] = 1
[my_info2_*] = 2
From this source:
#include <boost/exception/all.hpp>
#include <iostream>
typedef boost::error_info<struct my_info1_, int> my_info1;
typedef boost::error_info<struct my_info2_, int> my_info2;
struct my_error: public boost::exception, public std::exception { };
int main()
{
try
{
BOOST_THROW_EXCEPTION(my_error() << my_info1(1) << my_info2(2));
}
catch( boost::exception & e )
{
std::cout << boost::diagnostic_information(e);
}
}
use something that involves original_exception_type processing, such as say
try { try { BOOST_THROW_EXCEPTION(my_error() << my_info1(1) << my_info2(2)); } catch (...) { boost::rethrow_exception(boost::current_exception()); } } catch (boost::exception& e) { std::cout << boost::diagnostic_information(e); }
Your code outputs this:
example.cpp(15): Throw in function main
Dynamic exception type: boost::wrapexcept<my_error>
std::exception::what: std::exception
[my_info1_*] = 1
[my_info2_*] = 2
What is the problem?
try this:
try { auto const e = my_error() << my_info1(1) << my_info2(2); e << boost::original_exception_type(&typeid(e)); BOOST_THROW_EXCEPTION(e); } catch (boost::exception& e) { std::cout << boost::diagnostic_information(e); }
here's output produced for me (not quite accurate, still struggling with markdown):
Dynamic exception type: struct boost::wrapexcept
std::exception::what: Unknown exception *struct my_error[struct myinfo1 __ptr64] = 1**
[struct myinfo2 * __ptr64] = 2
unlike generalized version to_string( error_info<Tag,T> const & x )
I have my own custom extension to library that besides other features (such as customizing output for error_info_name according to end user dictionary, optionally choosing what types from error_info_map to include/exclude from generated diagnostic info string etc.) fix this annoyance for me but thought you might want to look into this