GNU bug report logs - #6855
24.0.50; Bug in tool bar label handling

Previous Next

Package: emacs;

Reported by: Johan Bockgård <bojohan <at> gnu.org>

Date: Sat, 14 Aug 2010 12:47:02 UTC

Severity: normal

Found in version 24.0.50

Done: Jan Djärv <jan.h.d <at> swipnet.se>

Bug is archived. No further changes may be made.

Full log


Message #22 received at 6855 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 6855 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#6855: 24.0.50; Bug in tool bar label handling
Date: Sun, 15 Aug 2010 07:41:49 -0400
> Date: Sun, 15 Aug 2010 12:21:37 +0200
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Cc: 6855 <at> 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.




This bug report was last modified 14 years and 288 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.