Re: [PATCH v2 5/7] lib: return NOTMUCH_STATUS_OPERATION_INVALIDATED where appropriate

Subject: Re: [PATCH v2 5/7] lib: return NOTMUCH_STATUS_OPERATION_INVALIDATED where appropriate

Date: Tue, 05 Aug 2025 08:39:34 -0300

To: Olly Betts

Cc: notmuch@notmuchmail.org, xapian-discuss@lists.xapian.org

From: David Bremner


Olly Betts <olly@survex.com> writes:
>
> In C++ the natural approach is to use multiple catch clauses to handle
> some error subclasses differently, i.e. something like:
>
>     try {
>         do_something_with_xapian();
>     } catch (const Xapian::DatabaseModifiedError&) {
>         do_something_special();
>     } catch (const Xapian::Error& e) {
>         report_error(e);
>     }

I think Anton's intent (and mine where I've tried similar tricks) is to
avoid duplicating boilerplate catch blocks. I guess it's mainly a matter
of taste. If we were writing the code from scratch, perhaps the
try/catch blocks could be re-arranged to reduce code duplication.

As an alternative to the current get_type based function, one could do
something like

static inline notmuch_private_status_t
_notmuch_xapian_error_private (const Xapian::Error &error)
{
  try {
    throw error;
  } catch (const Xapian::DatabaseModifiedError& _e) {
    return  NOTMUCH_PRIVATE_STATUS_OPERATION_INVALIDATED;
  } catch (const Xapian::Error& _e) {
    return NOTMUCH_PRIVATE_STATUS_XAPIAN_EXCEPTION;
  }
}

This is at least statically typed (mistyping a class name will be
caught, while mistyping a string constant will not). On the other hand,
I concede that using throw just to pattern match is also unfortunate.
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

Thread: