On Tue, 17 Aug 2004 03:15:01 -0600
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Michel Pelletier writes:
> > > We have to through an IndexError exception for Python. But that's not
> > > done yet.
> >
> > Okay, I'll keep depth checking. I thought about attempting a patch, but
> > Larry says return an undef containing an unthrown exception, Dan wonders
> > if it should be an empty undef, and you say throw an exception, so I'm
> > unsure what patch y'all want. ;)
>
> If it's a PerlArray, return an undef of some kind. It needn't contain
> an unthrown exception yet (but if you can figure out how to do that,
> great). A bare undef should be fine.
Well this is easy enough, but after trying it out I'm wondering its
usefulness. if an out of bounds get on an array returns an undef, then
bounds checking code must go through the same overhead to check for the
undef as it would need to initially just check the validity of the
bounds in the first place. Compare:
$I0 = .STACK
if $I0 > 0 goto .$NoError
new $P0, .Exception
$P0["_message"] = "Stack is Empty!"
throw $P0
.local $NoError:
pop $P0, .STACK
to
pop $P0, .STACK
isa $I0, $P0, "PerlUndef"
unless $I0 goto .$NoError
new $P0, .Exception
$P0["_message"] = "Stack is Empty!"
throw $P0
.local $NoError:
versus just throwing a catchable error if the array is empty on pop:
pop $P0, .STACK # throws exception
if Perl or other languages want an undef returned, it would seem to make
more sense that they assume to cost of catching the exception and
turning it into an undef, than everyone else turning the undef into an
exception. Popping an empty stack to feels much more "exceptional" to
me than an operation that results in an undef.
-Michel
