Floris Bruynooghe <flub@devork.be> writes:


>> - * This function will not return NULL since Notmuch ensures that every
>> - * message has a unique message ID, (Notmuch will generate an ID for a
>> - * message if the original file does not contain one).
>> + * This function will return NULL if triggers an unhandled Xapian
>> + * exception.

> How much of a departure from the existing API is this?  Will this be
> possible with all functions?  I had a quick look and tried some other
> functions that don't return notmuch_status_t:

It's upward compatible in that any code which crashes because it was not
expecting a NULL pointer, will already be crashing in the same
circumstances because of an uncaught exception / call to abort.

> notmuch_database_get_version currently returns and unsigned int and
> segfaults on use with a closed db.

Yes, the ones without a proper status value are going to be a bit work.

In the next series I just posted [1], I started providing status value
returning version (see notmuch_message_get_flag_st). We've been through
a few of these migrations and it has not been too painful.

> I wonder if a backwards-compatible errno-style API could work,
> notmuch_last_status(notmuch_database_t* database) or so.  This kind of
> thing is probably easy to adopt in bindings but harder for direct users
> of the API.  It's also an extra API call for everything that doesn't
> return notmuch_status_t.  But I'll leave the judgement to you, I'm not
> as experienced with the API.

I think my main objection to this is that there is no out-of-band value
to tell the caller they need to check errno. So basically every call to
to one of the relevant functions would need be followed by a call to
checking the error number. I don't think that's less work than switching
to a new API. Of course it's less work for me, and we already sort of
made that choice with notmuch_database_status_string. In that case it
was a matter of changing the entire API.  Here we're talking about 10
functions, and I'm not sure if they all need to be changed. For example
several of the notmuch_foo_valid functions just check pointers for being
NULL and can't generate I/O or exceptions.

d

[1]: id:20200704151805.3717715-1-david@tethera.net
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org