At 12:16 PM 8/27/00 -0400, Bennett Todd wrote:
The ramifications of some of these things are sufficiently
important that drawing attention to them might be a good thing.
In this case, note that Perl 6 will need to spell out which core
exceptions are by default fatal (eg, :arithmetic) and
2000-08-22-15:13:23 Peter Scott:
I too would rather say
my $fh = open $filename or die "Couldn't copy source: $!"
than
my $fh; try { $fh = open $filename } catch { die "Couldn't copy
source: ", $@-syserr }
I'd usually rather just say
my $fh = open
At 02:06 AM 8/24/00 -0600, Tony Olekshy wrote:
I just don't think that with with respect to the infrastructure
mechanism per se, "fatality" should have anything to do with it.
In the end, that's a judgement call; that's what we get paid the
big bux for ;-)
I have reservations about the
Glenn Linderman wrote:
Tony Olekshy wrote:
You are oversimplifying by mixing the notions of exceptions
and errors, whether you are aware of their difference or not.
I am aware of the difference between errors and exceptions;
however, I firmly believe that exception handling is the
Glenn Linderman wrote:
Here's some code that returns one non-fatal error. I'd like to
change it to use the new RFC 88 mechanism. Please show me how.
I've included how to do it via RFC 119. Note that sub
really_delicate_code is documented that only one possible
non-fatal error can occur,
Tony Olekshy wrote:
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
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:
Tony Olekshy wrote:
I just don't think that with with respect to the infrastructure
mechanism per se, "fatality" should have anything to do with it.
In the end, that's a judgement call; that's what we get paid the
big bux for ;-)
I have reservations about the
Glenn Linderman wrote:
I'm now reaching the conclusion that RFC 88 is apparently building
more mechanism around item 2 to make it prettier for use as a
general exception mechanism. If so, I don't think that is a
good idea.
In some ways you are oversimplifying the problem, and in other
Peter Scott wrote:
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
At 05:20 PM 8/23/00 -0700, Glenn Linderman wrote:
I'd appreciate your description of what you meant by orthogonal, it certainly
doesn't fit my definition, or that of my dictionaries, as far as I understand
mathematics. This dissertation on the meaning of the word orthogonal is, of
course,
Glenn Linderman wrote:
Tony Olekshy wrote:
Glenn Linderman wrote:
I'm now reaching the conclusion that RFC 88 is apparently
building more mechanism around item 2 to make it prettier for
use as a general exception mechanism. If so, I don't think
that is a good idea.
In
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
At 04:31 PM 8/23/00 -0400, Chaim Frenkel wrote:
"TO" == Tony Olekshy [EMAIL PROTECTED] writes:
The unwind logic would treat a scope with no exception set _as if_
each call were wrapped in at try block.
TO I don't think so. If no exception is in scope Perl should continue
TO to generate
At 12:41 PM 8/23/00 -0700, Glenn Linderman wrote:
But on the other hand, if you really want to trap both fatal and
non-fatal errors, doing it via a single general exception
mechanism is nice. How can we achieve both?
RFC 88 already achieves both, like this:
catch
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;
Markus Peter wrote:
I'm not sure though wether I like the usage of die to throw fatal
exceptions vs. throw for possibly non-fatal exceptions, especially
considering the fact that many modules currently use die for trivial stuff
like reporting wrong parameters...
Once a (more appropriate
--On 22.08.2000 12:24 Uhr -0400 Chaim Frenkel wrote:
TO return $FATAL_MODE ? ERROR_IO : throw Error::IO;
Why make all module authors do that? Have core perl do that for you.
Make a pragma that would treat throw as a return. No cost to the
module author.
This probably won't work. What
At 07:58 PM 8/22/00 +0200, Markus Peter wrote:
What I was actually requesting was a small pragma which simply turns off
all fatality, in the whole program, similar to what $SIG{__DIE__}
currently is able to do,
Are you sure? $SIG{__DIE__} cannot prevent the program terminating once it
Chaim Frenkel wrote:
What happens when Graham Barr decides to use throws in
his Net::* modules. These are some of the most useful modules that
I have been using. You have now forced me to switch to try/catch.
If Graham decides to use throws in Net::* he would be the one forcing
you to
--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
Peter Scott wrote:
Tony Olekshy wrote:
But, for simple scripts, Perl's inconsistency I just what I like.
Never thought I'd hear you say that :-)
Who, me? I'm a hopeless pragmatist. That's why I want try for big
programs. Pragmatically, that works better there. That's why I don't
I don't see how it gets more complicated if you really want to
ignore errors. If you really want to ignore errors, you have to do
this in Perl 5 right now anyway, but you say eval { ... }; instead.
open ( FOO, "$file" );
ignores errors.
eval ( open ( FOO, "$file" ));
ignores
On Tue, 22 Aug 2000, Glenn Linderman wrote:
throw an exception as a means of reporting "file is not there anyway" -
which I absolutely do not care about...
Well, if they die on you, there's not much you can do about it. But if they throw
an exception, you will only die if you don't catch
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
Tom Christiansen wrote:
Have all here please looked at
use Fatal qw(:void open close);
yet?
thanks,
Thanks for the gentle reminder Tom. Yes we have. When I use
the generic Cuse fatal; in my comments, I'm referring to just
that sort of functionality.
Everyone here seems to agree
Oops, accidentally sent message. Here's the final version.
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
Glenn Linderman wrote:
I think we agree that both/either type of APIs can be provided by a
module author with suitable wrappers. Or a module can provide one, and
another module written to wrap it and provide the other. I think we
agree that an exception, if thrown, should be caught and
Tom Christiansen wrote:
Have all here please looked at
use Fatal qw(:void open close);
yet?
thanks,
--tom
So that's a way of turning certain non-fatal errors into fatal errors for
the class of functions that happen to indicate non-fatal error via a false
return value. So what did
Chaim Frenkel wrote:
You are being extreme here. I use perl _because_ it is so
forgiving. I can easily do unlink("foo.err") and not check
return codes because I don't care if it was there before.
No sir, I am not being extreme. Don't Cuse fatal; and don't use
try/throw/catch/finally,
"TO" == Tony Olekshy [EMAIL PROTECTED] writes:
TO Chaim Frenkel wrote:
You are being extreme here. I use perl _because_ it is so
forgiving. I can easily do unlink("foo.err") and not check
return codes because I don't care if it was there before.
TO No sir, I am not being extreme. Don't
At 11:58 PM 8/22/00 +0200, Markus Peter wrote:
On Tue, 22 Aug 2000, Glenn Linderman wrote:
throw an exception as a means of reporting "file is not there anyway" -
which I absolutely do not care about...
Well, if they die on you, there's not much you can do about it. But if
they throw
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:
On Tue, 22 Aug 2000, Peter Scott wrote:
At 04:06 PM 8/22/00 -0500, Brust, Corwin wrote:
So that was:
Any exception raised in a try will be fatal unless caught?
It already is (RFC 88).
Two more questions ;-)
1) I could not find this in the online RFC 88 - what version are we
Markus Peter wrote:
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
Glenn Linderman wrote:
Some discussion has been made about ignoring errors from certain
parts of the code. This is the only item that gets more complex
with exception handling--they must be ignored explicitly
{ ignore_my_errors ( @params ); catch {}};
I don't see how it gets more
Peter Scott wrote:
Now, I do not want that to detract completely from Chaim's point,
which is well taken. I too would rather say
my $fh = open $filename or die "Couldn't copy source: $!"
than
my $fh; try { $fh = open $filename }
catch { die "Couldn't copy source: ",
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
Markus Peter wrote:
--On 22.08.2000 10:48 Uhr -0700 Glenn Linderman wrote:
What
I was talking about is that I cannot imagine that the perl core itself
magically transforms exceptions into return values as someone else
requested.
We agree here.
"enabling/disabling fatality for
Peter Scott wrote:
But surely you have to be consistent. I understood Chaim's point to be
that he wanted no exceptions if he didn't ask for them. If the core
currently dies where it could return and set $!, then it is being
inconsistent, since this is not an error that prevents perl from
At 02:29 PM 8/22/00 -0600, Tony Olekshy wrote:
Peter Scott wrote:
But surely you have to be consistent. I understood Chaim's point to be
that he wanted no exceptions if he didn't ask for them. If the core
currently dies where it could return and set $!, then it is being
inconsistent,
Tony Olekshy wrote:
Glenn Linderman wrote:
Some discussion has been made about ignoring errors from certain
parts of the code. This is the only item that gets more complex
with exception handling--they must be ignored explicitly
{ ignore_my_errors ( @params ); catch {}};
I
[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:
"TO" == Tony Olekshy [EMAIL PROTECTED] writes:
As for legacy. I strongly urge that Modules _never_ die.
It is extremely rude.
TO The contract between a module and its client is beyond the scope
TO of RFC 88. However, I take it from your strong stance that you
TO wrap every ++$i in an eval
Executive Summary:
We should go to a pure return-based mechanism for error signalling,
or a pure exception-based one. We can't do the former. Therefore
we should do the latter.
Author's Note:
I'm a pragmatist. I'll keep using return-based error signalling
for some purposes, just
45 matches
Mail list logo
