[boost-users][Test]BOOST_*_EXCEPTION/THRWO do not behave as expected?
For example: BOOST_CHECK_THROW( (throw "string exception"), std::exception ); I was expecting to get an error message in the form "error in xxx: exception<std::exception> expected". Instead a message like the following was logged: unknown location(0): fatal error in "xxxx": unknown type I'm not sure if this behavior is by design. If it is, it would be nice tools that catch all exceptions are provided. Thanks, Sean
"Sean Huang" <huangsean@hotmail.com> wrote in message news:BAY102-DAV1123743A2F03A66559A0CEA3F50@phx.gbl...
For example:
BOOST_CHECK_THROW( (throw "string exception"), std::exception );
I was expecting to get an error message in the form "error in xxx: exception<std::exception> expected". Instead a message like the following was logged: unknown location(0): fatal error in "xxxx": unknown type
I'm not sure if this behavior is by design. If it is, it would be nice tools that catch all exceptions are provided.
Unexpected exception is an error for any statement, for any tool. Common rule is that execution monitors deals with it (like in case above). BOOST_CHECK_THROW checks that particular exception gets thrown. There are 3 possible outcome: 1. No exception is thrown - error is reported by the tool 2. Expected exception is thrown - no error is reported 3. Unexpected exception is thrown - error is reported by test case monitor (the same would happened if an unexpected exception would happened in any other place) Do you think this particular tool needs to catch all unexpected exceptions? But in this case no information for these exceptions would be reported. Gennadiy
From: "Gennadiy Rozental" <gennadiy.rozental@thomson.com>
Unexpected exception is an error for any statement, for any tool. Common rule is that execution monitors deals with it (like in case above). BOOST_CHECK_THROW checks that particular exception gets thrown. There are 3 possible outcome: 1. No exception is thrown - error is reported by the tool 2. Expected exception is thrown - no error is reported 3. Unexpected exception is thrown - error is reported by test case monitor (the same would happened if an unexpected exception would happened in any other place)
Do you think this particular tool needs to catch all unexpected exceptions? But in this case no information for these exceptions would be reported.
I am too nervous about catching all exceptions and that's why I suggested providing both versions. One of the advantages of catching all unexpected exceptions in the macro is it would at lease provide the location of the exception whereas test case monitor cannot. Thanks for the prompt reply! Sean
I am too nervous about catching all exceptions and that's why I suggested providing both versions. One of the advantages of catching all unexpected exceptions in the macro is it would at lease provide the location of the exception whereas test case monitor cannot.
Actully the CVS version of UTF works so that test case monitor could point directly to the faulted statement. Gennadiy
From: "Gennadiy Rozental" <gennadiy.rozental@thomson.com>
I am too nervous about catching all exceptions and that's why I suggested providing both versions. One of the advantages of catching all unexpected exceptions in the macro is it would at lease provide the location of the exception whereas test case monitor cannot.
Actully the CVS version of UTF works so that test case monitor could point directly to the faulted statement.
I checked the CVS version but failed to see how it is different from the current behavior. To make sure I understand your point, did you mean that the test case monitor could actually point to where the throw statement is as in the example below? BOOST_CHECK_THROW( (throw "string exception"), std::exception ); Again, thank you very much for your help and a great library. Sean
I checked the CVS version but failed to see how it is different from the current behavior. To make sure I understand your point, did you mean that the test case monitor could actually point to where the throw statement is as in the example below?
BOOST_CHECK_THROW( (throw "string exception"), std::exception );
In cvs version of Test Tools implementation every tool calls BOOST_TEST_PASSPOINT and mark last line that was passed before execution tool expression. This way in above case It will know what was last point we passed in program execution was on above line. An error message would look like: unknown location(0): unknown error caught test.cpp(nn): last checkpoint <- this location of your statement Gennadiy
----- Original Message ----- From: "Gennadiy Rozental" <gennadiy.rozental@thomson.com>
In cvs version of Test Tools implementation every tool calls BOOST_TEST_PASSPOINT and mark last line that was passed before execution tool expression. This way in above case It will know what was last point we passed in program execution was on above line.
An error message would look like:
unknown location(0): unknown error caught test.cpp(nn): last checkpoint <- this location of your statement
Gennadiy, Thanks for the explanation. I checked the CVS again and saw BOOST_TEST_PASSPOINT() is added to BOOST_CHECK_IMPL and others but NOT BOOST_CHECK_THROW_IMPL. Maybe I looked at the wrong place or did not quite understand how it works. Could you please take a look? Thanks, Sean
Gennadiy, Thanks for the explanation. I checked the CVS again and saw BOOST_TEST_PASSPOINT() is added to BOOST_CHECK_IMPL and others but NOT BOOST_CHECK_THROW_IMPL. Maybe I looked at the wrong place or did not quite understand how it works. Could you please take a look?
Thanks you very much for noticing this. Fixed in cvs. Gennadiy
----- Original Message ----- From: "Gennadiy Rozental" <gennadiy.rozental@thomson.com>
An error message would look like:
unknown location(0): unknown error caught test.cpp(nn): last checkpoint <- this location of your statement
Another side-effect of not catching all exceptions is "expected_failures" would not work. But you may argue it is not expected failures anyways. Still, in this particular case, I would prefer giving users more options. Just my two cents. Sean
participants (1)
-
Gennadiy Rozental -
Sean Huang