Glenn Linderman wrote:
>
> Tony Olekshy wrote:
>
> > Hi, it's me again. Not to be a pain, but RFC 88 does say:
>
> Hey, no pain.
>
> > retry
>
> I do recall seeing this quote; however, replacing AUTOLOAD is a very
> specific instance of resuming from or retrying a fault condition. And
> e
Glenn Linderman wrote:
>
> These three recent postings expressing ways to implement the
> differences between RFC 119 and RFC 88 are encouraging. With a
> bit of syntactic sugar, it looks like RFC 88 can be made to handle
> all the cases I care about. Now if you'd just get rid of that
> "try"...
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
I've sent this version to the RFC librarian, but it hasn't shown
up yet. Until it does, it's available at:
Formatted: http://www.avrasoft.com/perl/rfc/rfc88v2.htm
POD as text: http://www.avrasoft.com/perl/rfc/rfc88v2.txt
This doesn't include Peter's latest changes yet, none of which
are show-
Glenn Linderman wrote:
>
> Tony Olekshy wrote:
>
> > Glenn Linderman wrote (in RFC 119 v2):
> > >
> > > It is not clear whether the finally clause is executed if
> > > the try statement is exited via a goto or return, but the
> > > statement is made that once a try statement is entered, it
Jarkko Hietaniemi wrote:
>
> I don't think we should assume that we can't scratch our nose without
> getting overly object-happy. For the particular aspect I'm driving at
> there is no *need* for objects of any kind, no catch, no throw, no
> structured exceptions: I want the program simply to _d
Peter Scott wrote:
>
> At 10:13 AM 8/23/00 -0600, Tony Olekshy wrote:
>
> >Making throw a method of Exception just means we don't have to say
> >
> > throw Exception->new("Can't foo.", tag => "ABC.1234", ...);
> >
> >and it means throw isn't a new keyword, and that throw $@ can,
> >invoked now
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
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
"try" the doesn't mean it isn't the
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
die), and one for so-called non-f
To use a $20 OO word, polymorphism. But this applies even if
$@ isn't an instance of an OO class, as explained herein.
If die/throw can put any data they want in $@, then before a
exception can be conditionally caught, the value of $@ must be
checked to see if it conforms to the intended check.
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.
This just popped into my head after reading Jarko's RFC. I had some
DBI heavy code which was making use of RaiseError. So like a good
programmer I'd wrapped all my DBI code in eval blocks. However, there
were a few cases where I forgot to check $@ after a block! This
allowed errors to silently
On Wed, Aug 23, 2000 at 04:32:43AM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> One Should Not Get Away With Ignoring System Call Errors
>
> =head1 ABSTRACT
>
> =head1 EXECUTIVE SUMMARY
>
> If something fails, you should care.
>
> =head1 DESCRIPTION
>
> The 'strict' pragma (or whateve
At 04:38 PM 8/22/00 -0600, Tony Olekshy wrote:
>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 hav
> I believe Dan said that he wanted to make objects a lot faster in P6. I
> don't think we should be precluded from requesting Things That Make Sense
> (tm) just because the current implementation is sub-optimal in performance
> if nothing inherently prevents a better implementation.
I don't
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
At 08:36 AM 8/23/00 -0600, Tony Olekshy wrote:
>Jarkko Hietaniemi wrote:
> >
> > On Tue, Aug 22, 2000 at 11:07:44PM -0700, Peter Scott wrote:
> > >
> > > I think this should be perl6-language-errors
> >
> > I scoured the -errors but all I could see was fancy-schmanzy talk
> > about OOish exception
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 10:13 AM 8/23/00 -0600, Tony Olekshy wrote:
>Making throw a method of Exception just means we don't have to say
>
> throw Exception->new("Can't foo.", tag => "ABC.1234", ...);
>
>and it means throw isn't a new keyword, and that throw $@ can,
>invoked now as an instance method rather than a
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
I'm replying to your first message because it contains more information,
but I'm also reading your second one in parallel while I respond.
Tony Olekshy wrote:
> Glenn Linderman wrote (in RFC 119 v2):
> >
> > RFC 119 wants to make available to the catch block exactly the
> > same list of par
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
I made some mistakes in my previous comments. Here are the relevant
items:
Tony Olekshy wrote:
>
> Glenn Linderman wrote (in RFC 119 v2):
> >
> > RFC 88 uses the finally keyword as a subclause introducer for
> > the try statement. RFC 119 uses the except and always keywords
> > as subclaus
--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
"Brust, Corwin" wrote:
>
> Tony Olekshy wrote:
> >
> > Throw can't take no arguments because it's a constructor
>
> If $@ always contains an exceptions we don't need to construct one to
> throw.
Um, but, $@ doesn't contain an exception until you throw an exception.
You still have to construct a
--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 (in RFC 119 v2):
>
> RFC 119 wants to make available to the catch block exactly the
> same list of parameters supplied to throw. This is prevented
> by RFC 88's stringification and concatenation of parameters.
Not quite true. You can't get exactly the same list, bu
-Original Message-
From: Tony Olekshy [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 22, 2000 8:26 PM
To: [EMAIL PROTECTED]
Subject: Re: Exception stack: let's use the @@ list.
> Ok, uncle.
Thanks.
Hey, when your right...
> I think C was already going to operate on $@ by default
Jarkko Hietaniemi wrote:
>
> On Tue, Aug 22, 2000 at 11:07:44PM -0700, Peter Scott wrote:
> >
> > I think this should be perl6-language-errors
>
> I scoured the -errors but all I could see was fancy-schmanzy talk
> about OOish exceptions, that's why I wrote the anti-OO section.
> Unless we get O
On Wed, Aug 23, 2000 at 08:17:18AM -0600, Tom Christiansen wrote:
> >"The first operation done on the return value of open() shall be defined()
> >or you shall regret your pitiful existence."? (a flag on the scalar coming
> >from open that makes any other op than defined() to die and defined() cle
>"The first operation done on the return value of open() shall be defined()
>or you shall regret your pitiful existence."? (a flag on the scalar coming
>from open that makes any other op than defined() to die and defined() clears
>the flag)
No -- just true or false suffices.
--tom
On Tue, Aug 22, 2000 at 11:07:44PM -0700, Peter Scott wrote:
> 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
I scoured the -errors but all I
> 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
Peter Scott wrote:
>
> If we were prepared to mandate that all system calls should return
> a value indicating success or failure *and nothing else*, I would
> probably not object to RFC 140 as is, but I think that would be
> unnecessarily crippling on the language.
Agreed. If one wants to make
44 matches
Mail list logo
