At 10:26 AM 8/27/00 -0400, Bennett Todd wrote:
So I'd expect instead
use Fatal qw(:arithmetic :io ...);
Therefore the default (to get the current behavior) would be that
some of the classes had Fatality enabled and others didn't?
And if Fatal supported unimport, then the default
Glenn Linderman wrote:
Tony Olekshy wrote:
Glenn Linderman wrote:
actually wrapping a bunch of code inside a try block
affects how that code reacts to die, thus affecting the
behavior of the program that previously used die to mean
terminate the program.
Hang on, this
Peter Scott wrote:
Yes, we get breakage; the user expects die to be trapped by eval.
It still would be.
Users of
Error.pm also expect it to be trapped by catch.
It still would be, if you 'use Error.pm'.
I do not think we should
maintain die/eval as a separate mechanism from try/catch;
At 02:37 PM 8/23/00 -0700, Glenn Linderman wrote:
This means that die can be trapped by catch, and
that throw can be trapped by eval.
Blecch. Orthogonality of the mechanisms is easier to understand than funny
rules, special cases, and syntactical magic.
But that *is* being orthogonal.
Chaim Frenkel wrote:
Tony Olekshy wrote:
If no exception is in scope Perl should continue to generate and
propagate exceptions (die and $@) as it does now, so we don't
break tradition.
No, that should be the difference between die and throw. Die is
immediately fatal. (i.e. current
--On 22.08.2000 10:48 Uhr -0700 Glenn Linderman wrote:
This probably won't work. What would you return exactly? Also, there's
plenty of chance that the return value could interfer with the regular
return values of that function... This will never be possible without
work done by the module
At 02:00 PM 8/22/00 -0600, Tony Olekshy wrote:
Peter Scott wrote:
I actually see nothing wrong in division returning undef for a
dividend of 0. It's just as easy to check as doing an eval.
Please don't do this. I would have to check every divide in all
my code, since no fatal is the
On Tue, 22 Aug 2000, Glenn Linderman wrote:
I'm suddenly intuiting that maybe you want to continue execution after the sub
call that caused the throw. But if you continue, you won't have the return
values from the sub call. Where should the continuation take place for
something like:
l1:
[snip]
-Original Message-
From: Markus Peter [mailto:[EMAIL PROTECTED]]
Another way to achieve the same result would be to NOT get rid of the try
part of try/catch and then try automatically implies use fatal for that
block...
--
Markus Peter
[EMAIL PROTECTED]
[/snip]
So that was:
At 04:06 PM 8/22/00 -0500, Brust, Corwin wrote:
[snip]
-Original Message-
From: Markus Peter [mailto:[EMAIL PROTECTED]]
Another way to achieve the same result would be to NOT get rid of the try
part of try/catch and then try automatically implies use fatal for that
block...
So that was:
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS From the reactions on this thread so far I am wondering whether the
PS message I sent out about it when it had a different name got
PS through. Relevant excerpt:
PS Well, you could certainly have a pragma that makes throw set $! to the
PS
Chaim Frenkel wrote:
Actually, why not simply unwind the call stack to the routine that
has the pragma active.
sub foo {use exception; baz()}
sub baz { throw "a fit" }
sub bar {
no exception;
foo();
}
Yes.
The
12 matches
Mail list logo
