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/ |
`. `' |
`- -><- |