> "DR" == Dave Rolsky <[EMAIL PROTECTED]> writes:
DR> On 22 Aug 2000, Chaim Frenkel wrote:
>> Could you tell me why you would want two finallys?
>>
>> Why not put them into one?
TO> my ($p, $q);
TO> try { $p = P->new; $q = Q->new; ... }
TO> finally { $p and $p->Done; }
TO> finally { $q and
[snip]
-Original Message-
From: Chaim Frenkel [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 22, 2000 12:43 AM
To: Tony Olekshy
Cc: [EMAIL PROTECTED]
Subject: Re: RFC 88: Possible problem with shared lexical scope.
Could you tell me why you would want two finallys?
Why not put them i
Chaim Frenkel wrote:
>
> Dave Rolsky wrote:
> >
> > Chiam Frenkel wrote:
> > >
> > > Tony Olekshy wrote:
> > > >
> > > > try { my $p = P->new;
> > > > my $q = Q->new;
> > > > ...
> > > > }
> > > > finally { $p and $p->Done; }
> > > > finally { $q and $q->Done; }
> > >
> > > Coul
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:
>> Syntactically the have to be next to one another, so write
>> them as one.
TO> If you write this:
TO> try { my $p = P->new;
TO> my $q = Q->new;
TO> }
TO> finally { $p->Done;
TO> $q->Done;
TO>
> "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
--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
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
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
Chaim Frenkel wrote:
>
> Tony Olekshy wrote:
> >
> > If you write this:
> >
> > try { my $p = P->new;
> > my $q = Q->new;
> > }
> > finally { $p and $p->Done;
> > $q and $q->Done;
> > }
> >
> > what happens if both constructors succeed, but $p->
--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
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
At 11:59 PM 8/20/00 -0600, Tony Olekshy wrote:
>RFC 88v2d6 now leaves in shared lexical scope and says the following
>under ISSUES + Lexical Scope:
>
> If it is not possible to have try, catch, and finally blocks
> share lexical scope (due, perhaps, to the vagaries of stack
> unwinding
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
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:
Peter Scott wrote:
>
> Given that even though we know the shared scope could be implemented,
> the implementors may prefer not to do it. I would therefore reword:
>
> > We would prefer that the blocks share a common lexical scope in the
> > way that C blocks used to; if this is deemed inappropr
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 ex
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
At 11:52 AM 8/21/00 -0500, Brust, Corwin wrote:
>I've come
>to like @_ as our input list and think that exception handling blocks would
>naturaly use this.
>
>Also it seems convienent, which seems perlish.
>
>Hmmm...
>
> for (@plays) {
> $qb->pass;
> warn &&
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
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
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:
>
At 12:43 AM 8/20/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > At 08:43 PM 8/19/00 -0600, Tony Olekshy wrote:
> > >Peter Scott wrote:
> > > >
> > > > Dave Rolsky wrote:
> > > > >
> > > > > Tony Olekshy wrote:
> > > > > >
> > > > > > die
> > > > > > If argument is anything else, ra
[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:
Peter Scott wrote:
>
> Brust, Corwin wrote:
> >
> > I've come to like @_ as our input list and think that
> > exception handling blocks would naturaly use this.
> >
> > Also it seems convienent, which seems perlish.
>
> I find myself indifferent on the subject of where the exception
> stack is sto
> Does this cover all the cases?
>
Does it allow not only die but everything w/in Carp.pm to be
implemented in terms of it?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Laziness with responsibility http://www.tipjar.com/kcpm
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
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
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
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
>> 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
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
> "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
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
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
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 LIS
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 {
>
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
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
# # -Original Message-
# # From: Tony Olekshy [mailto:[EMAIL PROTECTED]]
# # Sent: Tuesday, August 22, 2000 4:01 PM
# # To: [EMAIL PROTECTED]
# # Subject: Re: Exception stack: let's use the @@ list.
# # Peter Scott wrote:
# # >
# # > Brust, Corwin wrote:
# # > >
# # > > I've come to
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
"Brust, Corwin" wrote:
>
> Tony Olekshy wrote:
> >
> > Consider this case:
> >
> > catch $@->{severity} eq "Fatal" => { ... }
> >
> > Are you proposing to make @_ the exception stack in the catch
> > expressions too, as is:
>
> nope, just B C.
>
> catch grep $@->isa($_), qw( list_o_clas
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
-Original Message-
From: Tony Olekshy [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 22, 2000 6:27 PM
To: [EMAIL PROTECTED]
Subject: Re: Exception stack: let's use the @@ list.
That's well and good, but the source code syntax says it's a block,
not a sub. Am I supposed to spend the r
I have modified RFC 88 so that the following
=head1 DESCRIPTION
throw Exception::IO "a message", tag => "ABC.1234", ... ;
now reads like this:
=head1 DESCRIPTION
The most common forms of structured exception handling are straight-
forward. Here they are:
try { ... } catch { ...
"Brust, Corwin" wrote:
>
> > From: Tony Olekshy [mailto:[EMAIL PROTECTED]]
> >
> > That's well and good, but the source code syntax says it's a block,
> > not a sub. Am I supposed to spend the rest of my life asking myself,
> > "Wait, is this one of Corwin's special blocks?" ;-)
> >
> > I thin
Gads, people, I can barely go to the bathroom without getting behind on
this discussion, let alone head out for a few hours to pick up a new laptop
:-) I'll try to catch up.
At 07:25 PM 8/22/00 -0600, Tony Olekshy wrote:
>Throw can't take no arguments because its a constructor, not a function.
At 12:28 PM 8/22/00 -0700, I wrote:
The issue is not whether it is possible but whether it is desirable. Chaim
thought that the P5 continue block scope issue was 'fixed' by Gurusamy at
some point and this is almost certainly correct. Observe:
>% perl5.003 -Mstrict -we 'my $x = 2; while($x--)
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
>
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.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
object neutral error handling via exceptions
=head1 VERSION
Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Last Modified: 22 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
At 04:32 AM 8/23/00 +, Perl6 RFC Librarian wrote:
>One Should Not Get Away With Ignoring System Call Errors
> Mailing List: [EMAIL PROTECTED]
I think this should be perl6-language-errors
>In the following 'system calls' mean anything not in the core language
>calling an external service, b
53 matches
Mail list logo
