Closed GoogleCodeExporter closed 8 years ago
Original comment by shiq...@gmail.com
on 12 Oct 2008 at 3:20
Use --gtest_catch_exceptions on windows. I think this option is not supported on
linux and mac however.
Original comment by dalius.d...@gmail.com
on 23 Oct 2008 at 11:08
I've created a small patch to handle this on linux / mac,
maybe it's useful to someone else. The patch is for gtest 1.3.0.
For me this is way better than aborting the test runner.
Original comment by thomas.j...@intra2net.com
on 1 Jun 2009 at 11:54
Attachments:
Thomas,
Thanks for the contribution! There are couple of things I Need to mention.
First,
before we can accept code contributions from you we have to ask you to sign a
CLA.
Would you mind to do that? You can find details in
http://code.google.com/p/googletest/wiki/GoogleTestDevGuide#Contributor_License_
Agreements.
Second, implementing this feature correctly is a bit complicated. We have the
requirements that an implementation must conform to:
* On platforms that support SEH, gtest has to intercept SEH correctly
* On all platforms gtest has to intercept C++ exceptions correctly.
* The interception of C++ exceptions must be controlled by the
GTEST_FLAG(catch_exceptions). If the flag is not set, gtest should not try to
intercept them.
* gtest must not intercept debug breakpoints (initiated by the DebugBreak()
API) if
GTEST_FLAG(break_on_failure) is set. If it is not set, gtest must report debug
breakpoints as SEH exceptions.
* SEH exceptions should not be reported as C++ exceptions and vice versa.
If you are willing to take on the implementation, you are most welcome and we
will be
happy to advise you.
Original comment by vladlosev
on 2 Jun 2009 at 6:35
Thanks, I've handed those documents down to your legal department for review.
I've missed your reply to my patch as I didn't knew I needed to "vote" this
issue to
get email change notifications. Fixed it.
As I've never encountered SEH before, it really looks Windows specific to me and
seems to be supported well already. Also there is no such thing as a
DebugBreak()
API in the linux world, atleast not know to me.
If I understood all the requirements correctly, the only thing missing in the
patch
is the "GTEST_FLAG(catch_exceptions)" handling, right?
Hopefully we can sort out the legalese part ;-)
Original comment by thomas.j...@intra2net.com
on 9 Jun 2009 at 7:00
You are right, SEH is Windows specific. Since we support Windows as well, we
have to
take care of SEH. It is supported now but if we introduce C++ exception
handling, the
C++ exception handling on Windows must not interfere with SEH handling. MS
implemented C++ exceptions via SEH in a way that intercepting a C++ exception
can
also eat SEH exceptions passing through the same function. And on Windows,
segfaults
are reported via SEH. :-(
The DebugBreak() on Windows simply executes the 'int 3' assembler command
command.
The resulting interrupt is converted into a special SEH exception which the
debugger
treats as a debug breakpoint.
The code for Windows when both SEH and C++ exceptions are enabled should look
something like this:
void Test::Run() {
...
bool debug_break_intercepted = false;
try {
SehEnabledSetUp(&debug_break_intercepted);
}
catch (std::exception e) {
// std exception processing
}
catch (...) {
if (debug_break_intercepted) {
throw; // pass it on
} else {
// General exception processing.
}
}
...
}
void SehEnabledSetUp(bool* debug_break_intercepted) {
__try {
SetUp();
} __except(ShouldProcessSEH(GetExceptionCode(), &debug_break_intercepted)) {
AddExceptionThrownFailure(GetExceptionCode(), "SetUp()");
}
}
bool ShouldProcessSEH(DWORD exception_code, bool* debug_break_detected) {
if (GTEST_FLAG(catch_exceptions)) {
switch (exception_code) {
case EXCEPTION_BREAKPOINT:
*debug_break_detected = true;
return EXCEPTION_CONTINUE_SEARCH;
case EXCEPTION_CPP:
return EXCEPTION_CONTINUE_SEARCH;
default:
// This is neither C++ exception nor a break point. It's ours!
EXCEPTION_EXECUTE_HANDLER;
} else {
return EXCEPTION_CONTINUE_SEARCH;
}
}
Hopefully the entire sequence can be abstracted into a separate function so the
resulting code will not have to repeat it multiple times (SetUp,test body,
TearDown,
TestCaseSetUp, TestCaseTearDown). Yep, this is a bit complicated, isn't it? :-(
Original comment by vladlosev
on 15 Jun 2009 at 6:40
Increased priority due to user requests.
Original comment by w...@google.com
on 23 Dec 2009 at 7:00
Vlad, do you want to close this now? We can track the exception-death-test
interaction in a separate issue, as it's different.
Original comment by w...@google.com
on 8 Sep 2010 at 6:06
I consider this issue unfinished. Leaving aside the problem of how to treat
exceptions in death tests conceptually, there are some cases where this
implementation fails, while the previous (lack of) implementation succeeded.
E.g., EXPECT_DEATH(throw 1, ""); // Fails with the 'illegal return' message.
Original comment by vladlosev
on 8 Sep 2010 at 2:34
All apologies if this is off topic or inappropriate, but my interest in this
issue to be able to use --gtest_catch_exceptions on linux. Is that issue
tracked separately? This open request is the only hit I get if I search the
issues for catch_exceptions.
I tried applying the patch above to gtest as shipped with gmock 1.5.0 but at
this point it does not apply cleanly.
Original comment by nate.ha...@gmail.com
on 8 Sep 2010 at 3:02
Vlad, I agree there is more work to be done. I'm just saying that the
*original* issue, which is "uncaught exceptions thrown by a unit test should be
reported as failing tests", should be closed now, as gtest now does report
uncaught exceptions as test failures. By leaving it open, we lead people to
think that gtest still cannot report uncaught exceptions as failures.
The example you gave (EXPECT_DEATH(throw 1, "");) is about the interaction
between death tests and exceptions. Even though it's a regression, it's better
tracked by a separate issue. I'll create a issue for that.
Original comment by w...@google.com
on 8 Sep 2010 at 4:56
Original issue reported on code.google.com by
keith....@gmail.com
on 3 Oct 2008 at 9:03