Re: [lmi] Stylistic question about constructing error messages

[Greg Chicares]

On 2016-02-13 01:51, Vadim Zeitlin wrote:
> 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>         ;
> 
>  There are a couple of problems with using fatal_error(): first, it means
> dealing with all the alert functions machinery (including ensuring that the
> stuff is linked in and so on) which seems unnecessary for a simple command
> line tool.

Just clone 'ihs_crc_comp$(EXEEXT)' (e.g.) in makefiles; then write
  int try_main(int argc, char* argv[])
in your program instead of
  int     main(int argc, char* argv[])
and all that stuff is handled automatically. It catches exceptions,
flushes standard streams, etc., and is already widely reused.

> Second, the code can throw different exceptions, at least
> logic_error and invalid_argument as well as runtime_error and fatal_error()
> only supports the latter. I guess I could just use runtime_error everywhere
> but the two others seem more appropriate in the places where they're used...

It doesn't make any difference to the user whether this:

    fatal_error()
        << "Value for numeric field '"
        << name
        << "' is out of range (maximum allowed is "
        << max_num
        << ")."
        << LMI_FLUSH // A macro, yes, but a minimal, unavoidable one.
        ;

is a std::range_error, std::out_of_range, std::invalid_argument, or
std::runtime_error. A hierarchy of exceptions could be useful if we
were going to handle them in different ways, but I assume these all
result in termination with a diagnostic string printed.

>  I also admit that I have a dislike of fatal_error() due to its name

I suppose the name is unfortunate, because it suggests that termination
must ensue. We could change it globally someday; 'error' is too vague
for precise grepping, so I'd suggest:
  s/fatal_error/lmi_error/
and thus:
  s/warning/lmi_warning/
  s/status/lmi_status/

>  Do you think I should still use fatal_error() no matter these (perceived)
> problems?

Absolutely. We want this code to become part of lmi; it could be very
useful in the GUI. We don't want two parallel, nearly-identical
facilities for reporting errors.