On Sat, Feb 21, 2004 at 07:53:53PM +0100, Florent Rougon wrote: > Andrew Suffield <asuffield@debian.org> wrote: > > >> The description is very useful to the programmer. Much more useful than > >> a simple segmentation fault (I hope you don't run every binary under gdb > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> with debugging symbols enabled for day-to-day use). It is not very > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Of course not, I can extract a perfectly good stack trace from any > > core dump. It is not necessary to run binaries under gdb with > > debugging symbols enabled for this to work; why would it be? > > > >> useful to a clueless user, but this is a feature. An exception should > >> not be raised to the user. > > > > Well yeah, that's what we're talking about. What are you trying to > > say, again? > > I'm not trying to say, I'm saying that a Python program that aborts due > to an exception is: > 1. buggy > 2. more useful than something that aborts with no stack trace or a C > program that simply dumps core (or does not, depending on the > _user's_ ulimit settings). The user just has to copy-paste the > stack trace for the developper to be able to know where the bug > came from. > > Can you understand that? Yes, you've got no idea what I was talking about and have managed to be completely irrelevant. Try comparing a python program that aborts due to an exception with a program that handles the error and emits a proper error message. Then you might begin to approximate the subject. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
signature.asc
Description: Digital signature