Re: [lmi] Danger of fatal_error() (was: Stylistic question about constructing error messages)

[Vadim Zeitlin]

On Fri, 12 Feb 2016 23:12:36 +0000 Greg Chicares <address@hidden> wrote:

GC> Ultimately I anticipate integrating this into lmi, where I'd prefer to use
GC> lmi's fatal_error() instead...
GC> 
GC>     fatal_error()
GC>         << "Value for numeric field '"
GC>         << name
GC>         << "' is out of range (maximum allowed is "
GC>         << max_num
GC>         << ")."
GC>         << LMI_FLUSH // A macro, yes, but a minimal, unavoidable one.
GC>         ;

 I'd just like to know that this macro (or at least non-macro std::flush)
may well be minimal and unavoidable, but it's still quite dangerous because
the code compiles without any problems if you forget it but, of course,
doesn't work at all during run-time.

 In my case I had something like

        void do_something(some_type* ptr)
        {
            if(!ptr)
            {
            fatal_error() << ... long message ...;
            }

            ... dereference and use ptr ...
        }

and it took me quite some time to understand how this code could crash
dereferencing this pointer.

 Maybe I'm just particularly prone to errors, but I think it would be still
nice to use C++11 variadic function to write the above as

        fatal_error
            ("Value for numeric field '"
            ,name
            ,"' is out of range (maximum allowed is "
            ,max_num
            ,")."
            );

instead and never worry about forgetting LMI_FLUSH again. Of course, the
above doesn't append the file and line number automatically, but this could
be done either manually by just adding ",LMI_SOURCE_LOCATION" macro at the
end or by adding a macro fatal_error_with_location(...) which would do it
internally.

 Please let me know if you'd consider applying something like this. My
hopes are not high, but the safety benefit of my proposal is quite real.

 Regards,
VZ