Opened 17 years ago

Last modified 8 months ago

#3 assigned enhancement

Replace Xapian::ErrorHandler

Reported by: Olly Betts Owned by: Olly Betts
Priority: lowest Milestone: 1.4.x
Component: Library API Version: SVN trunk
Severity: minor Keywords:
Cc: Blocked By:
Blocking: Operating System: All

Description (last modified by 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.

Attachments (1)

db-error.diff (18.5 KB ) - added by Dan 8 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 by Olly Betts, 17 years ago

Status: newassigned

comment:2 by Olly Betts, 17 years ago

Severity: minorenhancement

comment:3 by Olly Betts, 13 years ago

Operating System: All
Version: otherSVN HEAD

comment:5 by Olly Betts, 10 years ago

Description: modified (diff)
Summary: Get multierrhandler1 working againTest coverage---- ''Original:'' Redo machinery in InMemory backend to allow multierrhandler1 to work. for Xapian::ErrorHandler

Description rewritten.

comment:6 by Olly Betts, 10 years ago

Summary: Test coverage---- ''Original:'' Redo machinery in InMemory backend to allow multierrhandler1 to work. for Xapian::ErrorHandlerTest coverage for Xapian::ErrorHandler

comment:7 by Olly Betts, 9 years ago

Milestone: 2.0.0

Probably 2.0.0 material.

comment:8 by Olly Betts, 8 years ago

Component: Test SuiteLibrary API
Summary: Test coverage for Xapian::ErrorHandlerDeprecate Xapian::ErrorHandler?

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.

comment:9 by Olly Betts, 8 years ago

Summary: Deprecate Xapian::ErrorHandler?Replace Xapian::ErrorHandler

Deprecated on trunk in r16456.

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

Last edited 3 years ago by Olly Betts (previous) (diff)

comment:10 by Dan, 8 years ago

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.

by Dan, 8 years ago

Attachment: db-error.diff added

comment:11 by Olly Betts, 5 years ago

Milestone: 1.3.x1.4.x

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.

comment:12 by Olly Betts, 4 years ago

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.

Last edited 4 years ago by Olly Betts (previous) (diff)

comment:13 by Olly Betts, 4 years ago

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

comment:14 by Дилян Палаузов, 8 months ago

Component: Library APIBuild system

comment:15 by Дилян Палаузов, 8 months ago

Component: Build systemLibrary API
Note: See TracTickets for help on using tickets.