[Xapian-devel] Error handling in the bindings

[Olly Betts]

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