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, :arithmeti
2000-08-27-12:03:07 Peter Scott:
> > use Fatal qw(:io ...);
> > no Fatal qw(:arithmetic);
>
> Bingo, yes. I will make appropriate changes to RFC 80. You might
> think about whether RFC 70 needs to be changed.
I don't think so; while I mention styles of changes and growth for
F
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
At 10:20 AM 8/27/00 -0400, Bennett Todd wrote:
>I'd usually rather just say
>
> my $fh = open $filename;
>
>and be done with it, but then I'd always "use Fatal qw(:all);". But
>if I'd done such a "use Fatal", and then wanted to catch one, I sure
>hope I wouldn't have such a rabid try/catc
2000-08-22-16:40:13 Peter Scott:
> >I'm not sure, but I think Chaim's main point was just that, not
> >that divide-by-zero should be ignored too.
>
> Well, it could be made user-selectable, right Bennett? Do you envisage
> being able to say
>
> use Fatal qw(Arithmetic IO etc)
>
> usi
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 $
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.
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 a
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 'sever
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 o
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
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 th
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.
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
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, some
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> At 02:28 PM 8/23/00 -0700, Glenn Linderman wrote:
>> Chaim Frenkel wrote:
>>
>> > No, that should be the difference between die and throw. Die is
>> > immediately fatal. (i.e. current semantics) throw is new and does
>> > the magic.
>> >
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.
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
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/catc
At 02:28 PM 8/23/00 -0700, Glenn Linderman wrote:
>Chaim Frenkel wrote:
>
> > No, that should be the difference between die and throw. Die is
> > immediately fatal. (i.e. current semantics) throw is new and does
> > the magic.
> >
> > We get no breakage that way.
>
>Hear, hear. That's (some of) w
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:
> >
> >
Chaim Frenkel wrote:
> No, that should be the difference between die and throw. Die is
> immediately fatal. (i.e. current semantics) throw is new and does
> the magic.
>
> We get no breakage that way.
Hear, hear. That's (some of) what RFC 119 proposes. Keep fatal error handling
and non-fatal e
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" == 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 and propagate exceptions (die and $@) as
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
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 some ways you are over
--On 23.08.2000 10:15 Uhr -0600 Tony Olekshy wrote:
> This form is documented as proposed in RFC 88:
>
> catch $@->{severity} eq "Fatal" => { ... }
>
> and I'm adding this to the next version, as a convenience method:
>
> catch $@->fatal => { ... }
Agreed. That one is better th
Markus Peter wrote:
>
> Glenn Linderman wrote:
> >
> > For example, if truly fatal errors could be distinguished, one
> > could declare that a catch-all clause "catch { ... }" would not
> > catch fatal errors, that it would be necessary to specifically
> > list that you want to catch a fatal error
--On 22.08.2000 20:51 Uhr -0700 Glenn Linderman wrote:
> For example, if truly fatal errors could be
> distinguished, one could declare that a catch-all clause "catch { ... }"
> would not catch fatal errors, that it would be necessary to specifically
> list that you want to catch a fatal error...
> 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 othe
Tony Olekshy wrote:
> Glenn Linderman wrote:
> >
> > Perl 5 doesn't have exceptions, which is precisely how it avoids this
> > problem.
>
> Perl 5 has exceptions. my $x = 0; my $y = 1 / $x; It avoids nothing,
> which is we are always mixing return-based and exception-based failure
> signalling.
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
>
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 do
Glenn Linderman wrote:
>
> Perl 5 doesn't have exceptions, which is precisely how it avoids this
> problem.
Perl 5 has exceptions. my $x = 0; my $y = 1 / $x; It avoids nothing,
which is we are always mixing return-based and exception-based failure
signalling. This is not going to go away, and
Markus Peter wrote:
>
> I could not find this in the online RFC 88 - what version are we
> talking about?
Sorry, it's available as below. This draft hasn't been sent to the
RFC index yet because I'm waiting on Peter's comments.
Formatted: http://www.avrasoft.com/perl/rfc/rfc88v2d5.htm
POD as
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 an
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 {
>
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 C in my comments, I'm referring to just
that sort of functionality.
Everyone here seems to agree th
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();
> }
Ye
> "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
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
>> 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" ));
>i
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 w
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 pl
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 a
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 th
[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:
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:
>
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 ); catc
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
> > inco
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 f
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 ex
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
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:
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 m
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
ret
--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 m
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 ch
Markus Peter wrote:
> --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 au
--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. W
> "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
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 C and don't use
try/throw/catch/finally, and
nothi
> "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
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 li
64 matches
Mail list logo
