[lmi] Exceptions and libxml++

[Greg Chicares]

Evgeniy--In 'configurable_settings.cpp', this function
  xmlpp::DomParser::parse_file()
is called in a try-block, while other uses of that function are
not. I'm guessing that this is only because the original xmlwrapp
implementation tested the parser state (with operator bool()) in
this case only, and not in the others. Or was there some other
reason?

It certainly seems strange to write

    try
      {parser.parse_file(filename);}
    catch(std::exception const& ex)
      {/* context_ or context_->directory is null */}

    if(!parser)
      {/* parser.doc_ is null */}

but that's apparently how this library works. It might be simpler
to rewrite that as

    try
      {
      parser.parse_file(filename);
      if(!parser)
        throw some_std_exception;
      }
    catch(std::exception const& ex)
      {
      complain...
      }

but I'm thinking of writing a "helper" function to do that, and
never calling parse_file directly anywhere else. IOW, I think
your "helpers" class looks like a good idea and might expand it.

BTW, what's the advantage of making the "helpers" a class (whose
members are all static public functions):

  // injecting into xmlpp namespace
  namespace xmlpp {
    class LmiHelper {
      public:
        static std::string get_content(Element const& node);

instead of just a bundle of free functions:

  namespace xml_stuff {
    static std::string get_content(libxmlpp::Element const& node);
    ...

? Does the class just behave as a sort of inner namespace, or is
there some name-lookup issue that I'm missing? (I recognize that
this lets you write 'Element' instead of 'libxmlpp::Element', but
I'm wondering if there's more to it than that--Koenig lookup or
something.)

Let me explain why I'm asking. I want to feel really certain that
we aren't introducing any new defects by migrating to libxml++.
It's different enough from xmlwrapp that I can't see at a glance
that every line is obviously correct. So, observing that we use
very few of the facilities of either library, I'm thinking of
abstracting out all those that we do use, and working through a
relatively small number of helper functions only. If I do that in
the trunk with xmlwrapp and on the branch with libxml++, then all
the differences will be in a "helpers" file, which can be unit
tested as exhaustively as we like. The other files should then be
easier to understand and maintain. And, even better, we'd get rid
of inconsistencies in the original code, like testing the parser
with operator bool() only in one file but not another.

And we could trap all exceptions, too. It looks like the only
exception xmlwrapp throws is bad_alloc, while apparently the
libxml++ maintainers are gradually moving in the direction of
throwing exceptions instead of returning error codes (though
I don't think they've yet done this consistently everywhere).

I don't know whether this will be as easy as I hope, but it might
be the easiest way for me to gain the deep understanding that I'd
like to have, so I'll explore the idea at least.