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
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
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
>
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
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
> >rule
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
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
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 exac
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
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 e
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. Whe
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
> >
>
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.
> > "en
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
Tony Olekshy wrote:
> Non-shared:
>
> my ($p, $q);
> try { $p = P->new; $q = Q->new; ... }
> finally { $p and $p->Done; }
> finally { $q and $q->Done; }
>
> Shared:
>
> try { my $p = P->new; my $q = Q->new; ... }
> finally { $p and $p->Done; }
> finally { $q and $q->Do
Peter Scott wrote:
> Technically, the only ones of these that impact the core are: message, and
> link. The others might be better broken out into another RFC. One RFC for
> throwing and handling exceptions; another one for what goes in the exceptions.
So that was one thing I tried to do in RF
"David L. Nicol" wrote:
> What I was suggesting was, if you want to overload the autoloading
> of something, it could be done with "catch" instead of rewriting
> the ::OVERLOAD procedure, for that module.
>
> "method not loaded" becomes an exception which is thrown, rather
> than "AUTOLOADING" b
23 matches
Mail list logo
