notmuch as a shared object aka library knigge

[Justus Winter]

Quoting Austin Clements (2012-02-21 16:53:12)
>Quoth Justus Winter on Feb 21 at  1:29 am:
>> Hi fellow notmuchrs,
>> 
>> while going through the python bindings I recently came across the
>> following note in the documentation for the Database.get_directory
>> function [0]:
>> 
>> ~~~ snip ~~~
>> Warning
>> 
>> This call needs a writable database in Database.MODE.READ_WRITE
>> mode. The underlying library will exit the program if this method is
>> used on a read-only database!
>> ~~~ snap ~~~
>
>This is a bug and should be thought of as such.

Agreed.

>INTERNAL_ERROR should
>only be used for internal library inconsistencies (e.g., things that
>should never ever happen) [...]

Well, I do not agree. If there is a inconsitency within the library
that library should report this to the caller and it is totally okay
to say that if the callee ignores this error, bad things will happen
(i.e. we're in unspecified behavior territory here).

It is still not okay to kill the whole process. Imagine you're using
the alot mail client that uses libnotmuch through the python bindings
and you've just finished writing a letter when libnotmuch decides to
commit suicide and prevent the python code from saving the draft.

For the record, there is libabcs README [0] that clearly states:

~~~ snip ~~~
Never call exit(), abort(), be very careful with assert()
  - Always return error codes.
  - Libraries need to be safe for usage in critical processes that
    need to recover from errors instead of getting killed (think PID 1!).
[...]
Always provide logging/debugging, but do not clutter stderr
  - Allow the app to hook the libs logging into its logging facility.
  - Use conditional logging, do not filter too late.
  - Do not burn cycles with printf() to /dev/null.
  - By default: do not generate any output on stdout/stderr.
~~~ snap ~~~

>This hasn't been fixed because it derives from an interface flaw.

Yes. And the interface flaw is the way error reporting is done within
libnotmuch. I've mentioned this once on the list and received little
feedback wrt how we can fix this kind problems if we need to change
the api to do so.

>As always, patches welcome!

Well, hacking on c code in my free time is not my idea of fun and I'm
not familiar with the code base, so I'd appreciate it if someone who
is in a better position to whip up a patch would step up and do so.

Cheers,
Justus

0: https://git.kernel.org/?p=linux/kernel/git/kay/libabc.git;a=blob_plain;f=README