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