Re: [lmi] Error reporting (was: An irreproducible anomaly)

[Vadim Zeitlin]

On Thu, 16 Jun 2016 03:44:18 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-06-16 01:08, Vadim Zeitlin wrote:
GC> 
GC> >  On a completely separate note, when doing this with some random text
GC> > (which turned out to be a part of another email), I got the following
GC> > message box:
GC> > 
GC> >   ---------------------------
GC> >   Error
GC> >   ---------------------------
GC> >   Symbol table for class class Input ascribes no member named 'VZ> '.
GC> >   ---------------------------
GC> >   OK   
GC> >   ---------------------------
GC> > 
GC> > This is true, as far as it goes, but I'd suggest that saying "Clipboard
GC> > doesn't contain valid census data" could be less incomprehensible to the
GC> > end users...
GC> 
GC> It's an eternal challenge. We can write really specific error messages
GC> that explain exactly what went wrong and help us diagnose and fix the
GC> problem, but end users cannot understand them. Or we can easily write
GC> vague but "friendly" error messages that don't help anyone because they
GC> all boil down to "That didn't work--try again". Or, at considerable cost,
GC> we can try to intercept messages from the "plumbing" and recast them in
GC> "porcelain" language.

 I don't think either of those is a good approach and while the
implementation is not always perfect, I still believe that the idea I had
20 years ago with wxLog is the least bad one: we need to generate *both*
the low level detailed messages and high level user-friendly ones and show
the latter one initially with the possibility to dig in into the former if
necessary (as an aside, I've changed my mind about a lot of things since
then, so the fact that I didn't do it about this one is, for me, a good
meta-argument in its favour).

 You don't have to use wxLog functions/dialog to implement this behaviour,
of course, although it's the simplest in a program using wxWidgets. But
this stack of error messages can be implemented in other ways, e.g. by
having an exception class with a pointer to next exception and a way to
conveniently re-throw a lower level exception wrapped into a higher-level
one with a more user-friendly error message.

GC> Apparently at some time in the past I hoped that a general routine
GC> like validate_filepath() could be widely used to validate filepaths,
GC> but I don't think that's actually possible. But trapping every possible
GC> error and writing a really good message for each one would take months.

 This is still true, of course. Giving good error messages is a lot of
work, but I think it's worth it. But at least with a stack-of-errors
approach you can write a low level helper like validate_filepath() to avoid
duplicating the code checking whether the file exists and is not a
directly.

GC> Returning to your example:
GC> >   Symbol table for class class Input ascribes no member named 'VZ> '.
GC> CensusView::UponPasteCensus() already seems to trap eight different
GC> kinds of invalid input. I'm not convinced that trapping a ninth would
GC> go to the root of the complex of problems this routine poses. Yet if
GC> you feel highly motivated to write and test a patch like (untested)
GC> 
GC> +        std::vector<std::string> const& 
all_headers(case_parms()[0].member_names());
GC>          while(std::getline(iss_line, token, '\t'))
GC>              {
GC> +            if(!contains(all_headers, token))
GC>                  {
GC>                  fatal_error() << "Name '" << token << "' not recognized." 
<< LMI_FLUSH
GC>                  }
GC>              headers.push_back(token);
GC>              }
GC> 
GC> then I'd be willing to apply it.

 I don't think it's the best way to solve the problem. I'd rather catch the
exception being currently thrown and do

        fatal_error()
                << "Clipboard doesn't contain valid census data "
                << "(" << e.what() << ")"
                << LMI_FLUSH
                ;

or something like that.

 Regards,
VZ