Peter Scott wrote:
Only one of them needs to be right. As long as one is right,
there is no problem.
Right, I was just pointing out that it's harder for people to divine which
one we picked without recourse to the documentation.
Yes; unfortunately, this problem exists generally,
or AUTOLOAD can be defined in terms of Ccatch
and overloaded that way, rather than being its own
kind of magic.
catch "AUTOLOAD-$classname-$polymorphicsignature" {...
Jonathan Scott Duff wrote:
On Wed, Aug 16, 2000 at 12:15:30PM -0500, David L. Nicol wrote:
If "catch" can be
At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
Perhaps, throw can carry a return value?
throw {"return value"} $exception;
If there is an active try/catch context then the $exception would
be propogated, otherwise $@ would get loaded with $exception and
the return value would be the
At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS 1. When an exception is thrown perl looks for the enclosing try block; if
PS there is none then program death ensues.
Err, if there isn't one. Don't throw the exception. Stop processing but
don't
"DLN" == David L Nicol [EMAIL PROTECTED] writes:
DLN =head2 eval/die remains perfectly workable
DLN as "die" is a perfectly serviceable method or raising an exception.
Actually, die is pretty nasty. Modules can't use it.
Another mechanism that means, short circuit, but let the user know
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
Perhaps, throw can carry a return value?
throw {"return value"} $exception;
If there is an active try/catch context then the $exception would
be propogated, otherwise $@ would get loaded with
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS 1. When an exception is thrown perl looks for the enclosing try block; if
PS there is none then program death ensues.
Err, if there isn't one.
Peter Scott wrote:
If that were so, even without the ignore() function, I could just say
sub Exception::IO::throw { 'do nothing' }
and kill it that way.
Right. Just like overriding core die. At that point you can
change the semantics in such a way as to turn your code into
Executive summary: I no longer want catch blocks to "daisy chain"
after a exception is thrown in a catch block. Thanks to everyone
who has helped me see the light on this.
Peter Scott wrote:
At 01:16 AM 8/16/00 -0600, Tony Olekshy wrote:
The proposed omnibus Exceptions RFC uses the
Peter Scott wrote:
Tony Olekshy wrote:
[snip]And the following output was generated:
Exception
$ = Try::throw('Exception') called from scott2.pm[8].
$ = main::pling('Test') called from scott2.pm[4].
$ = main::bar('Test') called from scott1.pl[1].
$ =
On Wed, Aug 16, 2000 at 11:49:03AM +0100, Graham Barr wrote:
if any of the catch or finally throws, it is caught by a
try {} block up the stack.
Keep It Simple
What he said.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
11 matches
Mail list logo
