At 12:43 AM 8/20/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > At 08:43 PM 8/19/00 -0600, Tony Olekshy wrote:
> > >Peter Scott wrote:
> > > >
> > > > Dave Rolsky wrote:
> > > > >
> > > > > Tony Olekshy wrote:
> > > > > >
> > > > > > die
> > > > > > If argument is anything else, raise a run-time
> > > > > > exception.
> > > > >
> > > > > So this probably shouldn't be the case.
> > > >
> > > > This sounds alright; there's something very self-defeating
> > > > about raising a run-time exception from dying badly, if you
> > > > see what I mean.
> > >
> > >Yes! That's why v1 of RFC 88 didn't do that. Thanks, Dave.
> >
> > Hmm, does this affect the idea of throw on an object that isn't an
> > exception being a run-time error? I hope not. throw and die
> > shouldn't have the list-joining behavior in common.
>
>But, since throw is a class/object method, how can throw Foo;
>effect a run-time error? By definition, if you're throwing
>an Exception you're throwing an Exception. How Exception class
>throw mechanisms connect to die must, in the end, be up to them.
>
>After all, if you're simulating a game, you could C<throw Ball;>.
Hmm, I don't get this. I thought the discussion was around how
throw object;
could be a run-time error if object ! isa Exception (which is what I think
should happen) if
throw LIST;
had to have the same semantics as die LIST. It means you have to
special-case throw to raise a run-time exception (er, of its own; not the
one its supposed to raise... how do you do that?) iff it has one argument
which is an object that doesn't derive from Exception. I know that sounds
weird, but I think whenever it happens, it almost certainly means that the
user thought they were throwing an Exception object and picked the wrong
one. In that instance, stringifying the object as though we were in the
throw LIST case would definitely not be helpful.
--
Peter Scott
Pacific Systems Design Technologies
