How do I test an exception with CppUTest

[A. Robert S.]

I am relatively new to C++ exceptions. I use them sparingly. Now I have a case where, if a critical file cannot be opened, the exception is caught, an error message printed, and the application exits with -1.

 

For one thing, I would like to say in the test, something like FAIL_IF_NO_EXCEPTION( ios_base::failure );

 

But, since the exception has been caught (as it should) and the application exits (as it should), unfortunately, my tests print the error and exit.

 

1. Are there designs that would make it easier to test exception handling? Any reading matter?

 

2. Does CppUTest offer any functionality to facilitate this (e.g. starting the test in a separate process and examining the return value)?

 

Thanks,

Robert

[Martin Ertsaas]

There are functionality to test if an exception is thrown, but it
demands that the expection is not catched by anyone (CHECK_THROWS is the
macro).

In your case, you are trying to test if the application actually dies,
which is not supported by CppUTest (If you really need to Google Test
supports this). Bas can give a lengthy explanation as to why this is
considered a bad idea, and therefor why it is not in CppUTest.

- Martin

> --
> You received this message because you are subscribed to the Google
> Groups "cpputest" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to cpputest+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[James Grenning]

Where do I look to find out how to use cake to create the files for visual studio?

Specifically I need vc6.

thanks, James

--------------------------------------------------------------------------------------------
James Grenning Author of TDD for Embedded C
www.renaissancesoftware.net http://pragprog.com/titles/jgade/
www.renaissancesoftware.net/blog
www.twitter.com/jwgrenning

[Martin Ertsaas]

When you have installed cmake, you can just start up the UI, input the
source directory of cpputest, and the build directory of your choice.

There is a drop-down menu where you can chose vc6, and then it should
create the visual studio files for you.

If you prefer the cmd, you can go to your build directory, do cmake
<source_directory> -G <visual studio generator> and the should be
created. Do cmake --help to see what the name of the vc6 generator is.

For resources you can look at:
http://www.cmake.org/cmake/help/documentation.html

- Martin

[A. Robert S.]

Hi Martin,

 

I new there was *something* in CppUTest. Thank you for pointing out CHECK_THROWS. To use this approach, I would need to move the catch right into the main() function, which currently I have designed to do nothing but the applciation classes Run() method.

 

Currently, the execption is caught right at the source of the error. In many ways, I like that better, because I don't have to disambiguate what exact exception I got (can be a bit hairy with iostream). On the other hand, I only request an exception to be thrown when I open a file without which the app cannot run.

 

Would you move out the catch into main(), if you were in my situation? Since I use a different main() for unit tests, it would then remain uncaught when testing.

 

Thanks,

Robert

[Martin Ertsaas]

I would catch the exception as close as possible, where I can do some sane fixing of the error. If you want to terminate the program anyway, I wouldn't catch it at all, but let the program be terminated by the exception.

Personally I think a try/catch in main is a bad idea. So the way I would solve this is one of two:

1) use CHECK_THROWS, and let the exception kill the program
2) If you don't want the exception to kill the program, don't try to test on an exception being raised. What are the side effect you want when the exception begin raised? If you, as an example, want to return an empty string, test that opening a non-existing file returns an empty string. In this case the exception is an implementation detail, and I would bother testing for it.

[James Grenning]

Thanks!

[A. Robert S.]

Okay. I was thinking along the same lines (catching it as close as possible to its origin.

The exception, if uncaught, is unhelpful. So I catch it, print a helpful message, as in:

   "Could not open input file XYZ"

What I really want to do is 

1) Print a helpful message and terminate the application, if the mandatory file could not be opened (the application used to continue silently and produce empty results, which was confusing users).

2) Test that, if the file could not be opened, the message is indeed printed.

I guess I could choose to not terminate the application. Terminating would be more like the behavior I'd expect as a user, but like before, no harm would be done if I allow it to continue. It will just generate empty results. It could then be tested more easily.

I realize I could implement these behaviors with or without exceptions; the real problem is terminating/exiting the application with an error, which would exit the test. 

I could use the "classical" approach - let the method return some value, maybe -1 instead of 0, and then test that value. I was hoping exceptions would be an improvement over that.......

[Bas Vodde]

Hola Robert,

Not catching an advantage for errors that should never happen has a huge advantage in debugging as it makes retrieving the stack trace relatively easy!

When you catch and print, it is often harder to get the stack trace. So therefore when there is something seriously wrong (not a user error) then terminating with an exception might be beneficial. (unless there is a way you can actually recover from the error or give the user *useful* information, but then you need to catch close to where you threw as the main loop tends to not know about the details)

Bas

[Martin Ertsaas]

If you let the exception terminate the program, you will at least get it
terminated. The alternative approach is to catch it where it happens,
print an error message to the user, and rethrow the exception. I would
only do that if it made sense to give a UI message on this though,
wouldn't bother if it were for logging.

- Martin

[Bas Vodde]

"The application experience an unknown error and will quit now" :)

Bas

[Martin Ertsås]

Exactly :)

[A. Robert S.]

Hiya Bas,

 

That is an excellent way to look at it.

 

In my case, I'd really consider it a user error (specifying a non-existant input file). One might choose not to use exception handling at all. As ist were, I moved the try-catch block out into the calling class, where I could more easily control the output, and now the test just looks for the error message. And that actually makes the exception an implementation detail.

 

If something really unexpected happened, then like you suggest, the exception wouldn't be caught, and it shouldn't.

 

Thanks again,

Robert,