CppUnit development mailing list
2014-02-18 11:51:08 UTC
Hi all,
I've saw some activity in the commit log last year, after years of
silence. Here's to hoping somebody is listening :-)
We're using cppunit extensively with a large code base, and we're
mostly happy with it. One thing we'd like to improve though, is crash
and exception reporting on Windows.
I've experimented with a structured exception filter to write out a
minidump (the Windows equivalent of a core dump), and it seems to work
well. So well, in fact, that I wonder if it should be our default
policy even for unknown C++ exception.
Unfortunately, since DefaultProtector catches (...), I never get a
chance to handle them, they're just logged as:
##Failure Location unknown## : Error
Test name: Test::TestAnyRandomException
uncaught exception of unknown type
which isn't very useful.
I'd like to propose splitting DefaultProtector into three individual
classes along the three catch clauses:
1) cppunit::Exception: these should be handled and reported as failures
2) std::exception: these are almost ubiquitous and should probably
continue to be reported as errors (though it might be nice to make it
opt-out)
3) (...): for any unknown exceptions it makes more sense (to me,
anyway) to let it slip and give a debugger a chance to extract
context.
Of course, this imposes a soft requirement for people to write a
custom protector for their custom exception types not derived from
std::exception (we have one) if they want to prevent their tests from
crashing hard.
Thoughts? Would you take patches to demonstrate what I mean in more detail?
Thanks,
- Kim
I've saw some activity in the commit log last year, after years of
silence. Here's to hoping somebody is listening :-)
We're using cppunit extensively with a large code base, and we're
mostly happy with it. One thing we'd like to improve though, is crash
and exception reporting on Windows.
I've experimented with a structured exception filter to write out a
minidump (the Windows equivalent of a core dump), and it seems to work
well. So well, in fact, that I wonder if it should be our default
policy even for unknown C++ exception.
Unfortunately, since DefaultProtector catches (...), I never get a
chance to handle them, they're just logged as:
##Failure Location unknown## : Error
Test name: Test::TestAnyRandomException
uncaught exception of unknown type
which isn't very useful.
I'd like to propose splitting DefaultProtector into three individual
classes along the three catch clauses:
1) cppunit::Exception: these should be handled and reported as failures
2) std::exception: these are almost ubiquitous and should probably
continue to be reported as errors (though it might be nice to make it
opt-out)
3) (...): for any unknown exceptions it makes more sense (to me,
anyway) to let it slip and give a debugger a chance to extract
context.
Of course, this imposes a soft requirement for people to write a
custom protector for their custom exception types not derived from
std::exception (we have one) if they want to prevent their tests from
crashing hard.
Thoughts? Would you take patches to demonstrate what I mean in more detail?
Thanks,
- Kim