Niall Douglas
On 5 Mar 2015 at 19:02, Louis Dionne wrote:
- // BOOST_HANA_RUNTIME_CHECK is equivalent to assert In that case, what is the point of using it instead of assert? I think you should probably avoid using these constructs in the user documentation of other parts of the library. It's just a distraction, so it's better to rely on standard components, which users probably already understand.
The problem is that `assert` is not define when NDEBUG is defined, but I want my tests to fire up all the time. Since these examples are Doxygen'd out of actual source files, the macros end up in the documentation. Basically, If I could redefine `assert` to be `BOOST_HANA_RUNTIME_CHECK` in those test files, I'd be really happy. Would it be against good software craftsmanship to write
... include all you need ...
#ifndef assert # define assert(...) BOOST_HANA_RUNTIME_CHECK(__VA_ARGS__) #endif
I'd suggest an alternative course: these are "current state is impossible" assertions right? In which case fatal application exit is the only valid outcome, plus you want them always there even in optimised builds, and ideally you want some sort of useful error message.
The *_CHECK macros in Hana are just meant to be used for unit testing. They should be enabled in all build configurations so I can test both the Debug and Release modes. Currently, BOOST_HANA_RUNTIME_CHECK(expr) is defined (roughly) as if (!expr) { std::cerr << "some useful error message"; std::abort(); } Of course it is less naive PP-wise, but that's the gist of it.
You may find my BOOST_AFIO_THROW_FATAL(x) macro of use here https://github.com/BoostGSoC13/boost.afio/blob/master/include/boost/af io/detail/Utility.hpp#L135. It tries to throw an exception in a noexcept function first, and if that succeeds (e.g. MSVC) then it calls std::terminate.
The print_fatal_exception_to_stderr() function dumps a stack trace to stderr on supported platforms, just to be very, very sure you get something debuggable. Most of AFIO's testing happens on a Jenkins CI to catch the really rare non-repeatable bugs, the ones not findable on your dev workstation, so having useful telemetry as to what went wrong is invaluable.
Thanks, I was wishing for a stack trace just earlier today. I'll take a look. Louis