From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#6855: 24.0.50; Bug in tool bar label handling Date: Sun, 15 Aug 2010 07:41:49 -0400 Message-ID: References: <877hjt1jue.fsf@gnu.org> <4C67A335.1050002@swipnet.se> <4C67BFB1.8030804@swipnet.se> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1281874139 13406 80.91.229.12 (15 Aug 2010 12:08:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 15 Aug 2010 12:08:59 +0000 (UTC) Cc: 6855@debbugs.gnu.org, schwab@linux-m68k.org To: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 15 14:08:58 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Okc1F-0005cQ-UP for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Aug 2010 14:08:54 +0200 Original-Received: from localhost ([127.0.0.1]:52116 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Okc1E-0001Hu-NJ for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Aug 2010 08:08:52 -0400 Original-Received: from [140.186.70.92] (port=52391 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Okc19-0001Hb-04 for bug-gnu-emacs@gnu.org; Sun, 15 Aug 2010 08:08:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Okc17-0006Wz-Id for bug-gnu-emacs@gnu.org; Sun, 15 Aug 2010 08:08:46 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51201) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Okc17-0006Wv-Cs for bug-gnu-emacs@gnu.org; Sun, 15 Aug 2010 08:08:45 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OkbaI-0001nC-1r; Sun, 15 Aug 2010 07:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Aug 2010 11:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6855 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6855-submit@debbugs.gnu.org id=B6855.12818724556884 (code B ref 6855); Sun, 15 Aug 2010 11:41:02 +0000 Original-Received: (at 6855) by debbugs.gnu.org; 15 Aug 2010 11:40:55 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OkbaB-0001mz-3o for submit@debbugs.gnu.org; Sun, 15 Aug 2010 07:40:55 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Okba9-0001mt-99 for 6855@debbugs.gnu.org; Sun, 15 Aug 2010 07:40:54 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1Okbb3-0003kq-Gm; Sun, 15 Aug 2010 07:41:49 -0400 In-reply-to: <4C67BFB1.8030804@swipnet.se> (message from Jan =?UTF-8?Q?Dj=C3=A4rv?= on Sun, 15 Aug 2010 12:21:37 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 15 Aug 2010 07:41:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:39503 Archived-At: > Date: Sun, 15 Aug 2010 12:21:37 +0200 > From: Jan Djärv > Cc: 6855@debbugs.gnu.org > > If the documentation states that one should use STRING, and somebody puts in > nil or a lambda expression or a symbol, that is a usage error. Being robust > against this kind of error by ignoring the faulty input just hides the error > and makes people think it is OK to misuse things. Better then to crash, that > way action is usually taken at once. Hidden errors can linger for years... Crash or hide are not the only alternatives. You can signal an error, for instance. Sometimes doing so is not a good idea, like in the middle of redisplay (because displaying the error message reenters redisplay again, and you have an infinite loop on your hands). For these situations, the solution is to display something prominent and acutely visible instead of the invalid data, so that it stands out and catches the user's eye. For example, if the menu item is bad, display something like "!!??GARBLED ITEM??!!" instead. In general, I agree with Andreas: it is better not to crash, if we can avoid that with a reasonable effort.