[boost test] question on exception testing
Hello *, I have a question regarding the tools BOOST_<level>_THROW: Why is it required to specify the exception being thrown? What if I don't know which exception is thrown, but I know that it should be thrown? My use case is: I have a worker class which executes some functionality. I know that the functionality will throw, but I would like to test that my class will remain in the consistent state after the exception was thrown? With BOOST_<level>_THROW(class_inst.execute()) I could spare the try{}catch(...){} block and make other test assertions, but unfortunately it is not possible, due to lacking of this utility. I would propose a throw guard into the lib, which does not produce any assertion, but swallows an exception. My intention is: I have to develop inside of a huge framework. The functionality I am trying to execute will only work on a target hardware. Since I am inside a debugger and not going to test the the executed functionality itself, but check the state of my class I think such a tool might help. With Kind Regards, Ovanes
Sorry, wrote some thing wrong. Please read further...
On Thu, Feb 28, 2008 at 7:29 PM, Ovanes Markarian
Hello *,
I have a question regarding the tools BOOST_<level>_THROW:
Why is it required to specify the exception being thrown? What if I don't know which exception is thrown, but I know that it should be thrown?
My use case is:
I have a worker class which executes some functionality. I know that the functionality will throw, but I would like to test that my class will remain in the consistent state after the exception was thrown? With BOOST_<level>_THROW(class_inst.execute()) I could spare the try{}catch(...){} block and make other test assertions, but unfortunately it is not possible, due to lacking of this utility.
I would propose a throw guard into the lib, which does not produce any assertion, but swallows an exception. My intention is: I have to develop inside of a huge framework. The functionality I am trying to execute will only work on a target hardware. Since I am -->inside a debugger<--
should be: since I am not testing on a target platform
and not going to test the the executed functionality itself, but check the state of my class I think such a tool might help.
With Kind Regards, Ovanes
Ovanes Markarian
Hello *,I have a question regarding the tools BOOST_<level>_THROW:Why is it required to specify the exception being thrown? What if I don't know which exception is thrown, but I know that it should be thrown?
What do you propose this tool should catch? ...? I don't think it's good idea. Why not std::exception? Gennadiy
And what if not std::exception compatible type is thrown? I don't see any
problems in this context, because I know that an exception will definitely
be raised.
What are your concerns about ... in this context?
Many thanks,
Ovanes
On Thu, Feb 28, 2008 at 10:04 PM, Gennadiy Rozental
Ovanes Markarian
writes: Hello *,I have a question regarding the tools BOOST_<level>_THROW:Why is it required to specify the exception being thrown? What if I don't know which exception is thrown, but I know that it should be thrown?
What do you propose this tool should catch? ...? I don't think it's good idea. Why not std::exception?
Gennadiy
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Ovanes Markarian
And what if not std::exception compatible type is thrown? I don't see any problems in this context, because I know that an exception will definitely be raised.What are your concerns about ... in this context?
catching ... is bad practice in general and I would prefer not to promote it. For example for vc 7.1 it will do wrong thing. IMO you should know what you are catching in your tests and check for it. Gennadiy
participants (2)
-
Gennadiy Rozental -
Ovanes Markarian