Peter Scott wrote:
>
> 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.
We can't do constuctor and LIST. The following would be ambiguous:
my $name = "Exception"; open $name or throw $name;
> 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.
I don't see how this can happen. If one says "throw Foo" and Foo
is not an exception, one will typically get some message about not
being able to find method throw for class Foo. If such a method can
be found I think it better be invoked, in case I say throw Ball;
where Ball is not an exception.
> [How can] throw raise a run-time exception (er, of its own; not
> the one its supposed to raise... how do you do that?)
sub throw
{
die $_[0]->isa("Exception") ? $_[0]->new(...)
: new Exception::NotException "...",
debug => join(", ", @_);
}
That is, if throw is a built-in. Otherwise, as I mentioned above,
this subroutine won't get invoked unless $_[0] already isa Exception.
If you want throw to reliably do object or string, then it has to
be a subroutine which takes a pre-built object or a string, like
this:
my $name = "Exception";
throw $name;
throw new Exception $name;
Peter once argued that he didn't want to new on every throw. I
agreed, and said, leave the matter of throwing string (lists) to
die. I still think that.
Yours, &c, Tony Olekshy
