Dynamic Exception Handlers [repost]
Can it really be two years ago that I talked about refactoring the mechanism in Boost.Python? http://aspn.activestate.com/ASPN/Mail/Message/boost/1537162 Well, I had to do it for a talk I'm giving, so here it is. It could easily be boost::detail-ized. Is there still interest? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u8y5nt5qs.fsf@boost-consulting.com...
Can it really be two years ago that I talked about refactoring the mechanism in Boost.Python?
http://aspn.activestate.com/ASPN/Mail/Message/boost/1537162
Well, I had to do it for a talk I'm giving, so here it is. It could easily be boost::detail-ized. Is there still interest?
I've implemented similar facilities in Boost.Test. Here is how latest (not cometted)version look like (abridged): namespace detail { class translate_exception_base { public: // Constructor explicit translate_exception_base( boost::scoped_ptr<translate_exception_base>& next ) // Destructor virtual ~translate_exception_base() {} virtual int operator()( unit_test::callback0<int> const& F ) = 0; protected: // Data members boost::scoped_ptr<translate_exception_base> m_next; }; template<typename Exception, typename ExceptionTranslator> class translate_exception : public translate_exception_base { typedef boost::scoped_ptr<translate_exception_base> base_ptr; public: explicit translate_exception( ExceptionTranslator const& tr, base_ptr& next ) : translate_exception_base( next ), m_translator( tr ) {} int operator()( unit_test::callback0<int> const& F ) { try { return m_next ? (*m_next)( F ) : F(); } catch( Exception const& e ) { m_translator( e ); return boost::exit_exception_failure; } } private: // Data members ExceptionTranslator m_translator; }; } class execution_monitor { public: int execute( unit_test::callback0<int> const& F, bool catch_system_errors = true, int timeout = 0 ); // register custom (user supplied) exception translator template<typename Exception, typename ExceptionTranslator> void register_exception_translator( ExceptionTranslator const& tr, boost::type<Exception>* = 0 ); private: // Data members boost::scoped_ptr<detail::translate_exception_base> m_custom_translators; }; // execution_monitor Usage look like this: boost::execution_monitor ex_mon; ex_mon.register_exception_translator<my_exception>( my_translator ); ex_mon.execute( function_to_monitor ); Isn't it what you are trying to do? Gennadiy
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
I've implemented similar facilities in Boost.Test. Here is how latest (not cometted)version look like (abridged):
Usage look like this:
boost::execution_monitor ex_mon;
ex_mon.register_exception_translator<my_exception>( my_translator );
You didn't show what my_exception looks like.
ex_mon.execute( function_to_monitor );
Isn't it what you are trying to do?
"Trying?" Of course I'm doing something similar, but I'm confused by the question: I was the one who pointed this technique out to you. Surely you grabbed most of your code out of Boost.Python (?) Anyway, the point of my exercise was to extract the mechanism into an easy-to-use general-purpose library with as little overhead as possible (e.g. no dynamic allocations are forced). If we still think there's a point in having such a general library (at least in detail), your particular interface choices could be implemented on top of it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7jl5riq6.fsf@boost-consulting.com...
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
I've implemented similar facilities in Boost.Test. Here is how latest (not cometted)version look like (abridged):
Usage look like this:
boost::execution_monitor ex_mon;
ex_mon.register_exception_translator<my_exception>( my_translator );
You didn't show what my_exception looks like.
ex_mon.execute( function_to_monitor );
Isn't it what you are trying to do?
"Trying?" Of course I'm doing something similar, but I'm confused by the question: I was the one who pointed this technique out to you.
I did not have a chance to look in detailed on the code you posted. It just seemed that there maybe something more beyond what I was trying to do. My question was just to clarify the difference. Sorry for confusion.
Surely you grabbed most of your code out of Boost.Python (?)
I did not grap the code I just followed the discussion we had at the time.
Anyway, the point of my exercise was to extract the mechanism into an easy-to-use general-purpose library with as little overhead as possible (e.g. no dynamic allocations are forced). If we still think there's a point in having such a general library (at least in detail), your particular interface choices could be implemented on top of it.
I wil need to look in more detailes. I could be not trivial. Also I couldn't afford all the dependencies you introduced. Gennadiy
-- Dave Abrahams Boost Consulting www.boost-consulting.com
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message
Surely you grabbed most of your code out of Boost.Python (?)
I did not grap the code I just followed the discussion we had at the time.
Okay.
Anyway, the point of my exercise was to extract the mechanism into an easy-to-use general-purpose library with as little overhead as possible (e.g. no dynamic allocations are forced). If we still think there's a point in having such a general library (at least in detail), your particular interface choices could be implemented on top of it.
I wil need to look in more detailes. I could be not trivial. Also I couldn't afford all the dependencies you introduced.
?? I was very careful to avoid dependencies. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
I wil need to look in more detailes. I could be not trivial. Also I couldn't afford all the dependencies you introduced.
?? I was very careful to avoid dependencies.
#include <boost/optional.hpp> #include <boost/function.hpp>
Oh, sorry, I'm not using boost/function; the #include is detritus. Optional is used, but it's really neccessary in order to give this thing the right interface. I suppose it might be possible to duplicate the functionality, but that would be a real shame. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7jl1c3vf.fsf@boost-consulting.com...
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
I wil need to look in more detailes. I could be not trivial. Also I couldn't afford all the dependencies you introduced.
?? I was very careful to avoid dependencies.
#include <boost/optional.hpp> #include <boost/function.hpp>
Oh, sorry, I'm not using boost/function; the #include is detritus. Optional is used, but it's really neccessary in order to give this thing the right interface. I suppose it might be possible to duplicate the functionality, but that would be a real shame.
In fact optional could be acceptable. AFAIK it's portable enough and I am considering using it myself. I still did not get a change to look in more details though. Gennadiy
participants (2)
-
David Abrahams -
Gennadiy Rozental