From: Carl Worth <cworth@cworth.org>
To: Sebastian Spaeth <Sebastian@SSpaeth.de>,
	Notmuch development list <notmuch@notmuchmail.org>
Subject: Re: Unhandled Xapian exception
In-Reply-To: <87aasul8h7.fsf@SSpaeth.de>
References: <87aasul8h7.fsf@SSpaeth.de>
User-Agent: Notmuch/0.2-174-g6ddc2e0 (http://notmuchmail.org) Emacs/23.1.1
	(i486-pc-linux-gnu)
Date: Sat, 24 Apr 2010 07:38:03 -0700
Message-ID: <87bpd8or04.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=

On Fri, 23 Apr 2010 13:21:56 +0200, "Sebastian Spaeth" <Sebastian@SSpaeth.de> wrote:
> I propose to try..catch this code block and rather than returning VOID
> it could return NOTMUCH_STATUS_SUCCESS or NOTMUCH_XAPIAN_EXCEPTION.
> Not sure how "notmuch_database_find_message" would notify the caller of
> such an exception situation though. The only possible failure value is
> NULL (which also means did not find such a message).

We haven't been doing fine-grained exception handling in the library so
far. Mostly because the assumption was that there was nothing we could
do---when I first wrote the code I assumed that Xapian exceptions would
be entirely exceptional.

So I just fixed the top-level entry point here to handle this exception
in our standard way, (print the message, then return NULL or
NOTMUCH_STATUS_XAPIAN_EXCEPTION).

While at this, I audited all notmuch_database calls to ensure they
follow this scheme. (I have not yet audited all libnotmuch entry
points.)

Meanwhile, we've recently discovered that there is a Xapian exception
that is not all that exceptional. Since database readers don't lock the
database, it's not hard to have one or more readers accessing the
database when a writer comes along and modifies the database. This
triggers the readers to subsequently fail with a DatabaseModified
exception.

I don't know how conceivable it would be to fix that at the Xapian
level. It might be quite nice if opening a database in read-only mode
gave access to a snapshot of the database as it exists at that time. But
that might be a feature that's entirely unreasonable to implement.

Otherwise, we might want to start supporting more clever handling of the
exception. For example, the high-level application might want to retry
an operation if it fails due to a DatabaseModified exception. To support
this, you would want your python bindings to have a layer that would
catch the C++ exception and re-throw a python exception.

And to support that, we would need a different scheme in the
library. Basically to just document that all calls might throw an
exception and then not catch and print anything. That would at least be
much simpler in the library. Then the top-level "notmuch" application
could just have a C++ wrapper for main() that would catch and print the
exception message.

What do you think?

-Carl

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFL0wJL6JDdNq8qSWgRAtTCAJ932UJpRa5Xo8A18sNeEGUtK06o3wCgodD7
elDDcN+LgfeCGGO6+bl3LYA=
=wE/h
-----END PGP SIGNATURE-----
--=-=-=--