Replace Xapian::ErrorHandler

[Olly Betts]

We used to have hooks in the library to allow the testsuite to make various cases in the inmemory backend fail to allow testing Xapian::ErrorHandler.

We don't really want these hooks in release builds, so they were removed. But it's hard to test many cases without something like this.

Probably leave until user database backends are possible, then we can take a "mock" approach to this problem by subclassing from an existing backend.

[Olly Betts]

Description rewritten.

[Olly Betts]

Probably 2.0.0 material.

[Olly Betts]

As we've discussed a couple of times on IRC in the past few months, Xapian::ErrorHandler was originally added as a fairly quick hack to allow webtop to handle a server not responding - it meant they could complete searches despite this, and log the lack of a response.

The documentation isn't really that great for it, but despite this I can't remember any user questions about it, or find any in my IRC logs or the mailing list archives. I also can't find any uses of it in Google's codesearch.

Thinking about the problem it is trying to address, I think ErrorHandler shouldn't be an Enquire-related feature - errors from working with a database outside of Enquire are interesting too.

There are related issues about which sub-database we're talking about in error messages, such as #329. Perhaps you should be able to specify a string "name" for a Database object which is just an opaque token to Xapian, to be reported in exceptions (and so available to ErrorHandler) - the Error class already has a "context" which we only use for remote databases I think. The name could default to something plausible, such as the pathname for disk-based databases.

Anyway, my proposal is to deprecate ErrorHandler and related API features in 1.3.0, and think further about a replacement, ideally to be added in 1.3.x.

[Olly Betts]

Deprecated on trunk in r16456.

We should sort out a replacement in 1.3.x if we can.

[Dan]

After a conversation on irc, there was a consensus that the ErrorHandler api should be moved to a set method on databases so users can choose to set a handler explicitly on different subdbs.

[Olly Betts]

I can still find no evidence of anyone using this class, nor any questions which suggest people are missing it. It's really high time 1.4.0 was released, so I think we postpone this. It could easily be dropped into 1.4.x as an API extension.

[Olly Betts]

ErrorHandler now is optionally referenced counted in [08f9f7fa2684d8171dc954aa6c92866b3946956f/git]. Nothing in the library yet uses this, but it's there for the future so this we can hook it up in 1.4.x when ErrorHandler is set on a DB.

As another aid to that, and since this is deprecated and apparently not used by anyone, I think we should make setting an ErrorHandler on Enquire a no-op for 1.4.0.

[Olly Betts]

[e3692bff7b7c25c8e09536889d5884d033199f36/git] makes setting an ErrorHandler a no-op (which will be in 1.3.5).

[Olly Betts]

[2399442c690b7c032c7e165ec9e4b647d0cb0955] removed the ErrorHandler class from git master (in 2017).

The original webtop motivation seems the main one here - i.e. when searching several remote servers, have a way to present results from those that respond even if one fails to. I struggle to see another realistic use case.

I don't believe we've had user requests for such a feature since webtop, which was over 20 years ago so I'm bumping the milestone for this.

The simplest way to handle this situation is just to retry the query - it means a slow response when a server fails and means setting timeouts appropriately matters, but it means the system always gives complete results. Results excluding one server are problematic as (a) users may notice if they fail to find a document they know is there and (b) further search results where the bad server does respond may be inconsistent (for example, narrowing the query by adding a term could return more results; also if paging does another search then the paging may be inconsistent).