"Rozental, Gennadiy" <[EMAIL PROTECTED]> writes:

>> > I could do something along following lines:
>> >
>> > #include <iostream>
>> > using namespace std;
>> >
>> > void
>> > unknown_exception_handler()
>> > {
>> >     try {
>> >         throw;
>> >     }
>> >     catch( int i ) {
>> >         cout << "int caught\n";
>> >     }
>> > }
>> >
>> >
>> > int main()
>> > {
>> >     try  {
>> >         throw 1;
>> >     }
>> >     catch( ... ) {
>> >         try {
>> >             unknown_exception_handler();
>> >         } catch( ... ) {
>> >             cout << "unknown exception\n";
>> >         }
>> >     }
>> > }
>> >
>> > and provide a way to configure unknown_exception_handler.
>> > Dave, do you have something different in mind?
>> 
>> Yes; check out
>> http://www.boost.org/libs/python/doc/v2/exception_translator.html
>> 
>> This allows multiple independently registered exception handlers.
>> Whether or not that's overkill for your purposes is another matter.
>
> If I understand the code properly, you proposing something along the
> following lines:
>
> struct exception_handler {
>     exception_handler( exception_handler* next = 0 ) : m_next( next ) {}
>     virtual ~exception_handler() {}
>
>     virtual void run( test_case, test_case_method ) = 0;
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^

If we are going to generalize this there should be a single
boost::function0<void> argument, and if you're going to go down this
path we should /definitely/ generalize it.  Replicating this design
pattern in two separate libraries would be a big mistake.

>
>     boost::scoped_ptr<exception_handler> m_next;
> };
>
> template<typename Exception, typename Translator>
> struct concreate_exception_handler : 

struct concrete_exception_handler : exception_handler

> {
>     concreate_exception_handler( Translator tr, exception_handler next = 0 )
>     : exception_handler( next ), m_translator( tr ) {}
>
>     virtual void run( test_case, test_case_method )
>     {
>         try {
>             if( m_next )
>                  m_next->run( test_case, test_case_method );
>             else
>                  test_case->*test_case_method();
>            }
>         catch(Exception const& e) {
>             m_translator( e );
>         }
>     }
>
>     Translator m_translator;
> };

Yes, something along these lines, though I don't like the naming; I
think the code from Boost.Python could almost be used as-is.

> Now unit test monitor could have member
> boost::scoped_ptr<exception_handler> m_eh and following logic
>
> a) in function
> if( m_eh )
>    m_eh->handle( test_case, method );
> else
>    test_case->*method()

This should be generalized into a static function of exception_handler
which takes a single function0<void> argument.

> b) add somehow register method
>
> template<typename Exception, typename Translator>
> void register_exception_handler( Translator tr ) 
> {
>     m_eh = new concreate_exception_handler<Exception,Translator>( m_eh );
> }
>
> It seems a little bit too complex in comparison with my solution, though
> implementable.

It's already implemented in Boost.Python.

>> note however that the try { throw; } idiom breaks on many popular
>> compilers that are still in use, which is why my code doesn't use it.
>
> What standard says about it?
> I just checked. MSVC6, bcc 5.5.1, gcc 2.95, gcc 3.2, SunPro 4.2 works as
> expected. What compilers do I really need to bother about?

MSVC6 does *not* work as expected (double-destruction of exception
objects), nor does gcc 2.95 (semi-random EH bugs and interactions with
optimization crop up).  This is not an idiom that's been
well-excercised in compiler vendors' test suites, it seems.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to