What steps will reproduce the problem?
1. Create a test which where the expression will throw an exception:
bool ThrowAnException()
{
throw 0;
}
TEST(Test, Exception)
{
EXPECT_TRUE(ThrowAnException());
}
2. Run the test
3. Check the result
What is the expected output? What do you see instead?
Expected output should be something like this:
[ RUN ] Test.Exception
test.cc:113: Failure
Unhandled exception caught in: ThrowAnException()
[ FAILED ] Test.Exception
But the current result is:
[ RUN ] Test.Exception
unknown file: Failure
Exception thrown with code 0xe06d7363 in the test body.
[ FAILED ] Test.Exception
What version of the product are you using? On what operating system?
1.0.1 on Windows
Please provide any additional information below.
The "unknown file: Failure" message is not so handy. At least the source
file and line should be reported.
Original issue reported on code.google.com by [email protected] on 16 Jul 2008 at 8:01
Hi,
Finally, here is my patch to solve this problem.
I've used the same trick that you used in death test macros. Thus only one
EXPECT_*
or ASSERT_* macro can be used in one line! (The same is true for ASSERT_DEATH
for
example.) I believe it is not a big restriction, however it is not for me to
decide..
I had to change the death test test, because you are using 2 EXPECT_ macro in a
death test macro which violates the new restriction. Maybe this will the
meaning of
that test also!
The format is maybe not perfect, but provides more information about the source
of
the error.
Catching is still controlled by catch_exceptions flag.
New tests implemented in gtest_unittest.cc to check the new feature.
Best regards,
Balazs
Original comment by [email protected] on 19 Jul 2008 at 1:00
Attachments:
Original comment by [email protected] on 31 Jul 2008 at 6:40
Original comment by [email protected] on 31 Jul 2008 at 6:40
Based on the complexity of the change and the likelihood of it breaking existing
code, we decided that it may not be worth it.
Original comment by [email protected] on 5 Aug 2008 at 7:15
I am sorry I am resurrecting this wontfix, but it sounds quite bad that it is
not possible to get the reason a test fails. It is completely opaque both on
the message output and on the debugging session, as the program exits without a
chance to check a backtrace with the debugger.
Original comment by [email protected] on 4 Jan 2015 at 12:42
Most helpful comment
Original comment by
[email protected]on 4 Jan 2015 at 12:42