At 06:48 PM 8/24/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
> > >
> > >In fact, not only would I be pleased and honoured to author the
> > >Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
> > >reference implementatio
Peter Scott wrote:
>
> At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
> >
> >In fact, not only would I be pleased and honoured to author the
> >Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
> >reference implementation.
>
> >Peter, I think we should make this approach more c
At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
>In fact, not only would I be pleased and honoured to author the
>Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
>reference implementation.
That should certainly tell you whether it's doable :-)
>Peter, I think we should make th
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.
Graham Barr wrote:
> Peter Scott wrote:
> > Tony Olekshy wrote:
> > > Graham Barr wrote:
> > > >
> > > > I am of the opinion that only a class name should follow
> > > > catch. If someone wants to catch based on an expression
> > > > they should use
> > > >
> > > > catch {
> > > > if () {
>
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
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> But the drawback would be that the actual victim may not be the primal
>> cause.
>>
>> sub foo {
>> my $fh = open();
>> ... Lots more code ...
>> return $fh;
>> }
>>
>> $victim = foo;
>> print $victim "I'm helpless";
JH> Tough.
Peter Scott wrote:
> At 11:21 AM 8/24/00 -0700, Glenn Linderman wrote:
> >By building up a
> >non-fatal error handling technique on top the existing fatal error
> >handling technique, you are forcing code that assumes it will die to
> >behave differently, when you wrap a try block around it. Now
Tony,
Having done the exercise of redoing all your RFC 88 examples into RFC 119
syntax, I conclude that the two biggest differences between the syntaxes is
the explicit or implicit try, which is mostly an irrelevant placeholder;
some like it, some don't.
The biggest syntax simplifications came i
At 11:21 AM 8/24/00 -0700, Glenn Linderman wrote:
>By building up a
>non-fatal error handling technique on top the existing fatal error
>handling technique, you are forcing code that assumes it will die to
>behave differently, when you wrap a try block around it. Now it will only
>"maybe" die.
Tony Olekshy wrote:
> Other than for the except and always clauses, RFC 199 is very
> similar to RFC 88. I like the idea behind except and always,
> but I think the proposed implementation could be dramatically
> simplified.
>
> The first thing to realize is that just because 119 doesn't say
> "
Tony Olekshy wrote:
> Some discussion has suggested that it might be a good idea if it
> were possible to have a simple way to prevent catch from catching
> so-called "fatal" errors. Some fringe ideas have actually included
> two seperate mechanisms, one for so-called fatal errors (based on
> di
Tony Olekshy wrote:
> There you have it. That's why RFC 88 uses structured data for $@.
That's a good argument, one that I have no quarrel with. As an
enhancement to eval/die, this would make it more flexible for checking
conditions. And with appropriate stringification, it is upward
compatib
Tony Olekshy wrote:
> Yes, well, at this point I must re-iterate that (in light of reasons
> for the existence of a try keyword that I have explained in other
> messages), what you've written is the same as:
>
> try { ... } finally { &do_something(); }
Yes, they are equivalent.
And note
Tony Olekshy wrote:
> Glenn Linderman wrote:
>
> > I do recall seeing this quote; however, replacing AUTOLOAD is a very
> > specific instance of resuming from or retrying a fault condition. And
> > even though a retry mechanism could be generalized from AUTOLOAD to
> > handling other conditions,
On Thu, Aug 24, 2000 at 02:09:15PM -0400, Chaim Frenkel wrote:
> > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> JH> "The first operation done on the return value of open() shall be defined()
> JH> or you shall regret your pitiful existence."? (a flag on the scalar coming
> JH> fr
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> "The first operation done on the return value of open() shall be defined()
JH> or you shall regret your pitiful existence."? (a flag on the scalar coming
JH> from open that makes any other op than defined() to die and defined() clear
On Sun, Aug 20, 2000 at 09:23:20AM -0700, Peter Scott wrote:
> At 10:14 AM 8/20/00 -0600, Tony Olekshy wrote:
> >Graham Barr wrote:
> > >
> > > I am of the opinion that only a class name should follow catch.
> > > If someone wants to catch based on an expression they should use
> > >
> > > catch
On Thu, Aug 24, 2000 at 10:47:45AM -0700, Peter Scott wrote:
> > > But I initially wanted to do without the => ... unfortunately that would
> > > require another keyword to handle the EXPR case and it didn't seem
> > worth it.
> >
> >Not necessarily.
> >
> > catch { EXPR } { ... }
At 12:50 PM 8/24/00 -0500, Jonathan Scott Duff wrote:
> > How should the parser disambiguate
> >
> > my ($hash,%hash);
> > try { ... } catch $hash { ... }
> >
> > ? But if we require the comma, we know it's parseable, because map can
> do it.
>
>map is a slightly different animal because
On Thu, Aug 24, 2000 at 10:10:49AM -0700, Peter Scott wrote:
> At 12:07 PM 8/24/00 -0500, Jonathan Scott Duff wrote:
> > > catch Alarm => { ... }
> > > catch Alarm, Error => { ... }
> > > catch $@ =~ /divide by 0/ => { ... }
> >
> >The => here seems like useless syntax to me.
>
> Au c
At 12:07 PM 8/24/00 -0500, Jonathan Scott Duff wrote:
> > catch Alarm => { ... }
> > catch Alarm, Error => { ... }
> > catch $@ =~ /divide by 0/ => { ... }
>
>The => here seems like useless syntax to me.
Au contraire... it emerged from our discussion of this case:
> catch EXP
On Thu, Aug 24, 2000 at 03:37:59PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Omnibus Structured Exception/Error Handling Mechanism
Woohoo!
> catch Alarm => { ... }
> catch Alarm, Error => { ... }
> catch $@ =~ /divide by 0/ => { ... }
The => here seems like useless synta
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
On Thu, 24 Aug 2000, Peter Scott wrote:
PS> From the beginning of the posting you're quoting:
PS>
PS> This RFC has been merged into RFC 88. The text of the last version
PS> prior to the merge is left below for archival purposes only. Anyone
PS> interested in browsing this for historical reasons
At 07:54 PM 8/24/00 +0400, Ilya Martynov wrote:
>PRL> Exceptions are objects belonging to some C class. Cing
>PRL> an exception creates the object; therefore, C above is just a
>PRL> class name (possibly including some C<::>).
>PRL>
>PRL> The C function is just syntactic sugar for creating a new
PRL> Exceptions are objects belonging to some C class. Cing
PRL> an exception creates the object; therefore, C above is just a
PRL> class name (possibly including some C<::>).
PRL>
PRL> The C function is just syntactic sugar for creating a new
PRL> exception class;it merely amounts to C<@EXCEPTI
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Omnibus Structured Exception/Error Handling Mechanism
=head1 VERSION
Maintainer: Tony Olekshy <[EMAIL PROTECTED]>
Date: 08 Aug 2000
Last Modified: 23 Aug 2000
Version: 2
Mailing List: [E
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Exception handling syntax
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last-Modified: 23 Aug 2000
Version: 4
Mailing List: [EMAIL PROTE
Glenn Linderman wrote:
>
> Tony Olekshy wrote:
>
> > RFC 88 does say:
> >
> > finally { ... }
> >
> > Once the try block is entered, every finally block is
> > guaranteed to be entered before the try statement completes,
> > whether or not any exceptions have been raised since th
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
32 matches
Mail list logo
