Re: [boost] [Hana] Informal review request

Subject: Re: [boost] [Hana] Informal review request
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-03-05 20:11:39

Niall Douglas <s_sourceforge <at> nedprod.com> writes:

> 
> 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