Is it possible to use Catch with -fno-exceptions?

[hh9527]

As title

[alecazam]

Agreed, most of the apps that I work explicitly forbid exceptions (f.e. Emscripten based targets). We turned on exceptions for Catch, but it slows down the compile times, and the runtime immensely. I appreciate the cleanliness of the API, but a set/longjump approach when exceptions are off would open this unit test framework up to more codebase. There doesn't appear to be a way to only enable exceptions on the unit test cpp files. I prefer to run unit test at startup of the actual app, so you can always be testing.

[refi64]

but a set/longjump approach when exceptions are off would open this unit test framework up to more codebase

Pretty sure what completely screw up RAII and stack unwinding...

[GatoRat]

setjmp/longjmp are unreliable and should never be used.

Seems the best solution would be to create a separate GitHub project for it.

[nabijaczleweli]

The longjmp() function family is literal cancer.

[alecazam]

I'm well aware of what set/longjmp do and their ramifications on destructors, and goto are evil too, but when you need them you need them. The reliance on exceptions in this unit test framework leaves little in the way of alternatives.

I'm not too concerned about leaking memory from the Catch framework, and aren't the exceptions only used on failures? The typical use case here is to launch with unit test at that start, and then fail the application from running if the unit tests do. So the stack unwinding doesn't seem too serious in this case.

[alecazam]

Setting some sort of error state with early returns before the next macro is another alternative.

[nabijaczleweli]

Just use C if you want *jmp*(). Dabble not in C++ therewith. I might or might not have done Very Bad things to a PC with 'em.

[alecazam]

Here's an excerpt from the Google unit test framework. Catch would be a lot more useful if it followed suit:

https://github.com/google/googletest/blob/master/googletest/docs/Primer.md
Google C++ Testing Framework works on different OSes, with different compilers (gcc, MSVC, and others), with or without exceptions, so Google C++ Testing Framework tests can easily work with a variety of configurations.

[nabijaczleweli]

Catch != GTest. If you want -fno-exceptions then use GTest. -fno-exceptions is out of scope for Catch.

[alecazam]

I understand that you like exceptions.

[ruipacheco]

-fno-exceptions would be nice.

[magreenblatt]

How about adding a configuration that #ifdef's out all functionality (THROWS macros, etc.) related to exception handling? Existing usage of "throw X" could be wrapped in a macro or function and implemented differently in cases where exceptions are disabled (for example, print an error message and crash). That seems like a reasonably clean approach that also preserves stack traces.

[nlohmann]

I would also like a version that is compilable with -fno-exceptions. While it is nice to have the -e command line parameter, it does not help if the code to be testet needs to rely on the STL not throwing.