Re: [lmi] Stylistic question about constructing error messages

[Vadim Zeitlin]

On Sat, 13 Feb 2016 17:20:15 +0000 Greg Chicares <address@hidden> wrote:

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

 OK, I'll do this, thanks.

GC> > Second, the code can throw different exceptions, at least
GC> > logic_error and invalid_argument as well as runtime_error and 
fatal_error()
GC> > only supports the latter. I guess I could just use runtime_error 
everywhere
GC> > but the two others seem more appropriate in the places where they're 
used...
GC> 
GC> It doesn't make any difference to the user whether this:
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>         ;
GC> 
GC> is a std::range_error, std::out_of_range, std::invalid_argument, or
GC> std::runtime_error. A hierarchy of exceptions could be useful if we
GC> were going to handle them in different ways, but I assume these all
GC> result in termination with a diagnostic string printed.

 In soa_tool, yes. But I thought we could want to handle them differently
if this code is ever integrated into the GUI because there is a difference
between having wrong data in an input file (runtime_error due to external
factors) and passing a wrong table index to some function (invalid_argument
due to a bug in the program).

GC> >  I also admit that I have a dislike of fatal_error() due to its name
GC> 
GC> I suppose the name is unfortunate, because it suggests that termination
GC> must ensue. We could change it globally someday; 'error' is too vague
GC> for precise grepping, so I'd suggest:
GC>   s/fatal_error/lmi_error/
GC> and thus:
GC>   s/warning/lmi_warning/
GC>   s/status/lmi_status/

 The last two are fine, but lmi_error() is now _insufficiently_ frightening
because it's not clear that this function is going to throw an exception
and not return. I'd prefer lmi_throw_error() or even just lmi_throw().
Perhaps something like lmi_error_no_return() could do as well, but I think
it's very valuable to have a reminder that this function doesn't return.

 Could you find some name which would have "throw", "exception" or
"no_return" in its name and yet be acceptable to you? This is not urgent at
all, of course, especially because I found a bug in handling of select
tables (not all ages are consecutive, after all...), so I'm busy with
fixing it right now anyhow. But if you can think of something more explicit
than lmi_error() but less fearsome than lmi_fatal(), it would be great.

 Thanks in advance,
VZ