Xapian devel - Mar 2007 - Error handling in the bindings

Currently, the SWIG generated bindings catch exceptions raised by Xapian 
and rethrow them using the standard SWIG error types: for example, if 
any Xapian::DatabaseError exception is raised, SWIG will use its
standard SWIG_IOError error type to report the error.

In Python, this leads to code like the following:

try:
     db.get_document(1)
except RuntimeError, e:
     if str(e).startswith('DocNotFoundError:'):
         # Handle a DocNotFoundError

(Incidentally, the error raised in python for this actually is a 
RuntimeError, not an IOError as I would have expected from reading the 
SWIG code, but that's not a major issue.)

For Python, it would be much nicer to have the full exception heirarchy 
of Xapian mirrored as Python classes, with the appropriate inheritance 
structure.  This is probably true for other languages too.  Looking at 
the code, I don't think it would take terribly long to sort this out for 
Python, but I haven't looked at what's needed for the other bindings we 
support.  It would certainly be much nicer to be able to write the above 
Python snippet as:

try:
     db.get_document(1)
except xapian.DocNotFoundError, e:
     # Handle a DocNotFoundError

In theory, the good thing about using the built in SWIG error handling 
system is that we don't have to write code for each language we support 
- but we already have conditional code for PHP for exceptions, so I 
don't feel that we'd be loosing much here.

The recent reworking of the way that the C++ code for the error classes 
is generated might make it possible to generate the SWIG interface code 
for the error classes for each language reasonably easily, and it would 
be nice to get this done before we release 1.0 if possible, so unless 
someone shouts up with a reason that it's not a good idea to try this, 
I'll try making a patch to fix up the Python exception handling next 
week, to see how feasible it is.

-- 
Richard

On Sat, Mar 03, 2007 at 01:05:05AM +0000, Richard Boulton
wrote:
> try:
>     db.get_document(1)
> except RuntimeError, e:
>     if str(e).startswith('DocNotFoundError:'):
>         # Handle a DocNotFoundError
This is probably the worst thing about the bindings at present.
> For Python, it would be much nicer to have the full exception heirarchy 
> of Xapian mirrored as Python classes, with the appropriate inheritance 
> structure.  This is probably true for other languages too.  Looking at 
> the code, I don't think it would take terribly long to sort this out
for
> Python, but I haven't looked at what's needed for the other
bindings we
> support.
For all those that support classes with inheritance and throwing classes
as exceptions, I think it should be fairly easy.

Of the SWIG bindings, Python and C# do.  Ruby almost certainly does, but
I don't know it very well.  PHP5 does, but PHP4 doesn't support
exceptions (the current approach is clumsy, but probably about as good
as we're likely to get there).  Tcl8 essentially only supports throwing
a string from what I recall (but I could be wrong).

And of the non-SWIG bindings, Java does, and Perl effectively does (the
mechanism is a bit different though).
> In theory, the good thing about using the built in SWIG error handling 
> system is that we don't have to write code for each language we support
> - but we already have conditional code for PHP for exceptions, so I 
> don't feel that we'd be loosing much here.
Not just for PHP.  There's special code for Tcl too (in tcl8/util.i).

I've been gradually trying to move all the language specific stuff into
the subdirectories, but as you may notice I have a long way to go!
> The recent reworking of the way that the C++ code for the error classes 
> is generated might make it possible to generate the SWIG interface code 
> for the error classes for each language reasonably easily
Indeed - it's something I had in mind when I reworked that.
> and it would be nice to get this done before we release 1.0 if
> possible, so unless someone shouts up with a reason that it's not a
> good idea to try this, I'll try making a patch to fix up the Python
> exception handling next week, to see how feasible it is.
I think it would be very useful.  And 1.0 would be a natural point to
make such a change.

I am starting to wonder at the number of things that have been noted
as "ought to be done for 1.0" though.  It would be good to get it
released for the UTF-8 support.  Perhaps we should remember that we can
have another "flag day" release for API changes, database changes, etc
and just sort out any loose ends and release it.

Hmm, that sounds a bit critical.  I don't mean to say you shouldn't
work on this at all.  I'm just articulating some "roadmap" type
thoughts
I had recently.

Cheers,
    Olly