Re: [lmi] Exceptions and libxml++

[Evgeniy Tarassov]

On 10/17/06, Greg Chicares <address@hidden> wrote:
> 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?

Yes, it is only because libxmlpp library does not guarantee that after
a successfull (exception-less) call to parse_file its operator bool()
will return true. In other words, even if parse_file succeeds we can't
be certain that parser has successfuly parsed the file. Looking at the
source code in libxml++/parsers/domparser.cc::DomParser::parse_context()
one can see that parse_file throws if during the document parser there
was any error, which means that "success on parse_file"=>"operator
bool()==true", but it is not documented. Plus in theirs own examples
they use it exactly the same way -- both a try block and an if
statement.

> 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...
>       }

Yes, i should have done it that way, sorry.

>   // injecting into xmlpp namespace
>   namespace xmlpp {
>     class LmiHelper {
>       public:
>         static std::string get_content(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.)

If i remember correctly there were no magic behind (like Koenig name
lookup you have previously mentioned). That helper class name should
consist of at least three words:
"xmlpp" - it is connected to libxml++,
"helper" - it is only a helper class which has no meaning as a standalone class,
"lmi" - it is a helper for lmi

A name like 'LmiXmlppHelper' could seem to be too long to type and
less readable, because libxml++ classes and methods are "marked" with
"xmlpp::" and not with that wierd "Xmlpp" which does not look "right".
'lmi_xmlpp_helper' would be nice, but 'xmlpp::LmiHelper' is even nicer
because that "xmlpp::" looks more familiar and if in some place we
have already imported xmlpp namespace (using xmlpp;) we will gladly
omit that "xmlpp::" part of the fully qualified name for the helper
too.
There was no real important reason behind that class naming, only some
visual aesthetics.

> 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.

I have noticed that too -- xmlwrapp and libxml++ class interfaces look
very similar. As you have mentioned they handle errors differently and
it would be lovely to have the same wrapper-interface, but there are
some important differences in the way these libraries handle DTD and
namespaces. And probably normalizing that part of both interfaces
could turn to be hard. Or maybe for lmi's purposes it is simply not
needed.