From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id kIYnAxT9+V4NHAAA0tVLHw (envelope-from ) for ; Mon, 29 Jun 2020 14:39:16 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id ELeAOhP9+V7CfgAA1q6Kng (envelope-from ) for ; Mon, 29 Jun 2020 14:39:15 +0000 Received: from arlo.cworth.org (arlo.cworth.org [50.126.95.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 376B09400BF for ; Mon, 29 Jun 2020 14:39:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id D4FA66DE13D6; Mon, 29 Jun 2020 07:39:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFwNMMQVgMAJ; Mon, 29 Jun 2020 07:39:09 -0700 (PDT) Received: from arlo.cworth.org (localhost [IPv6:::1]) by arlo.cworth.org (Postfix) with ESMTP id 27A966DE0F37; Mon, 29 Jun 2020 07:39:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id E7AF06DE0F37 for ; Mon, 29 Jun 2020 07:39:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLNgp-hTeHPn for ; Mon, 29 Jun 2020 07:39:05 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTP id 5688A6DE0226 for ; Mon, 29 Jun 2020 07:39:04 -0700 (PDT) Received: by fethera.tethera.net (Postfix, from userid 1001) id 3F4C7613B6; Mon, 29 Jun 2020 10:39:03 -0400 (EDT) Received: (nullmailer pid 2122733 invoked by uid 1000); Mon, 29 Jun 2020 14:39:02 -0000 From: David Bremner To: Floris Bruynooghe , notmuch@notmuchmail.org Subject: Re: Usage after database close In-Reply-To: <877dvqltg7.fsf@tethera.net> References: <87d05je1j6.fsf@powell.devork.be> <87d05jkvry.fsf@tethera.net> <875zbazzlu.fsf@powell.devork.be> <87a70mlu24.fsf@tethera.net> <877dvqltg7.fsf@tethera.net> Date: Mon, 29 Jun 2020 11:39:02 -0300 Message-ID: <87wo3qj5rt.fsf@tethera.net> MIME-Version: 1.0 X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: notmuch-bounces@notmuchmail.org Sender: "notmuch" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 50.126.95.6 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Spam-Score: 0.49 X-TUID: tOvcF5IRLAtj David Bremner writes: > David Bremner writes: > > >>> But part of my question is, *should* this be improved? Am I >>> interpreting notmuch's intended API correctly? >> >> Well, I agree you should get NOTMUCH_STATUS_XAPIAN_EXCEPTION back, or we >> should change the docs to say "just don't do that". > > Arguments in favour of the latter: > > 1) several API calls don't return notmuch_status_t, so can't literally > return NOTMUCH_STATUS_XAPIAN_EXCEPTION > > 2) notmuch_message_get_{message,thread}_id promise never to return NULL, > has no way to report errors. > > I think it would probably make sense to say (if notmuch_database_reopen) > existed, that if you call notmuch_database_close, don't call anything > else except notmuch_database_reopen or notmuch_database_destroy. I belatedly realized the exception is being caught, but then because of a lack of an error path (and presumably thinking this error was unlikely / impossible), INTERNAL_ERROR is called. This is not great for bindings either. Regardless of how the API docs are updated, the current calling of INTERNAL_ERROR should be avoided. I think I know what to do, it's just a matter doing so with a sensible amount of boilerplate and changes. d