9f/aef1349bfcb6d517dd83547b21f859d043afd4

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