--- /dev/null
+Return-Path: <amdragon@mit.edu>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 3C050431FD2\r
+ for <notmuch@notmuchmail.org>; Sun, 29 Jan 2012 17:55:04 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id 1+znGtMwX4pg for <notmuch@notmuchmail.org>;\r
+ Sun, 29 Jan 2012 17:55:03 -0800 (PST)\r
+Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU\r
+ [18.7.68.37])\r
+ by olra.theworths.org (Postfix) with ESMTP id 9DAA3431FBC\r
+ for <notmuch@notmuchmail.org>; Sun, 29 Jan 2012 17:55:03 -0800 (PST)\r
+X-AuditID: 12074425-b7f4a6d0000008e0-06-4f25f875f5d8\r
+Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])\r
+ by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP\r
+ id 6D.83.02272.578F52F4; Sun, 29 Jan 2012 20:55:02 -0500 (EST)\r
+Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
+ by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id q0U1t1Km006178; \r
+ Sun, 29 Jan 2012 20:55:01 -0500\r
+Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
+ (authenticated bits=0)\r
+ (User authenticated as amdragon@ATHENA.MIT.EDU)\r
+ by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q0U1sxwr026535\r
+ (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
+ Sun, 29 Jan 2012 20:55:00 -0500 (EST)\r
+Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)\r
+ (envelope-from <amdragon@mit.edu>)\r
+ id 1RrgRf-0000LO-Dt; Sun, 29 Jan 2012 20:54:11 -0500\r
+Date: Sun, 29 Jan 2012 20:54:11 -0500\r
+From: Austin Clements <amdragon@MIT.EDU>\r
+To: Justus Winter <4winter@informatik.uni-hamburg.de>\r
+Subject: Re: error handling and stderr\r
+Message-ID: <20120130015411.GL17991@mit.edu>\r
+References: <20120129180124.23430.33656@thinkbox.jade-hamburg.de>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Content-Disposition: inline\r
+In-Reply-To: <20120129180124.23430.33656@thinkbox.jade-hamburg.de>\r
+User-Agent: Mutt/1.5.21 (2010-09-15)\r
+X-Brightmail-Tracker:\r
+ H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1i37oepv8Okoo8Xs1h9MFtdvzmR2\r
+ YPKYeP40m8ezVbeYA5iiuGxSUnMyy1KL9O0SuDIev5At2CRScfPAKaYGxo0CXYycHBICJhIP\r
+ L99mgrDFJC7cW8/WxcjFISSwj1Hi7+0mKGcDo0RLZzMLhHOSSeL3jrXMEM4SRomDrVPYQPpZ\r
+ BFQlTk9+yAxiswloSGzbv5wRxBYRMJXY8OABO4jNLGAkcX/HdLAaYQE1iSNdq1hBbF4BHYnZ\r
+ 786DzREScJTYfuQPO0RcUOLkzCcsEL1aEjf+vQS6lQPIlpZY/o8DJMwp4CRx/9A7sJGiAioS\r
+ U05uY5vAKDQLSfcsJN2zELoXMDKvYpRNya3SzU3MzClOTdYtTk7My0st0rXQy80s0UtNKd3E\r
+ CAprdhfVHYwTDikdYhTgYFTi4d1ZoeovxJpYVlyZe4hRkoNJSZTX9TtQiC8pP6UyI7E4I76o\r
+ NCe1+BCjBAezkgjvnGVAOd6UxMqq1KJ8mJQ0B4uSOK+m1js/IYH0xJLU7NTUgtQimKwMB4eS\r
+ BO9xkKGCRanpqRVpmTklCGkmDk6Q4TxAw6+B1PAWFyTmFmemQ+RPMSpKifNuBkkIgCQySvPg\r
+ emFp5xWjONArwrybQKp4gCkLrvsV0GAmoMHPGcAGlyQipKQaGEWP3juy8O/sA28UZE2YuSZO\r
+ uXd8x37bA/5LmZRztjO0fuiaZm73+GLF46tNs/I6DHqbEjns30lsn9Yk8HHmYkGTK3vCQr2P\r
+ 7Ew5IsrI6CUp/2wpV6X/1KqDwdN9NfYFuAfK+d9eZWC3J1ebTd6F+ajz1BOqbGpi+5z1GAWl\r
+ haS8leMOztv4QomlOCPRUIu5qDgRAN2neF0WAwAA\r
+Cc: notmuch mailing list <notmuch@notmuchmail.org>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Mon, 30 Jan 2012 01:55:04 -0000\r
+\r
+Quoth Justus Winter on Jan 29 at 7:01 pm:\r
+> Hi notmuch developers,\r
+> \r
+> currently there is no way to determine why opening a database using\r
+> notmuch_database_open fails. I suppose that this is a problem for all\r
+> functions returning a pointer, but it is especially problematic for\r
+> this function since one cannot distinguish between a temporary failure\r
+> (someone else opened the db read/write) and a configuration problem\r
+> (wrong path).\r
+> \r
+> This is a real problem for providing sensible feedback to the user.\r
+\r
+I'm in the process of fixing the temporary failure, which I suspect is\r
+the biggest problem with the lack of status return, but you're right\r
+that a function as involved as notmuch_database_open really needs a\r
+way to distinguish failure types. Carl even left a note about this in\r
+notmuch.h in 2009.\r
+\r
+We could fix this without breaking the API by introducing a second\r
+variant of notmuch_database_open. I'm actually not a fan of this; I\r
+think notmuch is young enough and the library has few enough consumers\r
+that it's pointless to lug around compatibility code when the\r
+alternative is distinctly better. If we're really concerned about\r
+compatibility, I think we should move to using versioned symbols.\r
+\r
+> And writing an error message to stderr is a sensible thing to do if it\r
+> is done in a command line utility but doing so within a library is a\r
+> severe problem for any curses frontends and is generally considered a\r
+> bad practice.\r
+\r
+This is an unfortunate consequence of C's terrible error handling. I\r
+don't know how to do this effectively if we want error messages to\r
+accompany errors (which account for almost, though not quite all\r
+prints to stderr from libnotmuch). We could maintain a "last error\r
+message" on the database object, but then we have to be sure to update\r
+this on any error.\r
+\r
+We could simply provide a log hook. It's not very satisfying, but it\r
+may address the immediate problem of corrupting curses displays.\r
+\r
+What I find most frustrating about the current error handling approach\r
+is that it's always unclear whether a caller should report an error\r
+message or if the callee has already taken care of it (and generally\r
+with greater detail). Log hooks don't particularly help with this.\r
+\r
+> For the record, libabcs README[0] agrees with me on both aspects.\r
+> \r
+> Since fixing this means breaking the api we need to discuss this\r
+> thoroughly and identify all the functions involved.\r
+> \r
+> Users of the python bindings won't be affected by an api change like\r
+> this since we're converting any error code to exceptions anyway.\r
projects / notmuch-archives.git / commitdiff