On Wed, Aug 16, 2000 at 04:49:15PM -0500, David L. Nicol wrote:
>
>
> or AUTOLOAD can be defined in terms of C
> and overloaded that way, rather than being its own
> kind of magic.
>
> catch "AUTOLOAD-$classname-$polymorphicsignature" {...
But why should I have to know that a sub I want
At 09:14 PM 8/16/00 -0600, Tony Olekshy wrote:
>Jonathan Scott Duff wrote:
> >
> > I can almost see what you're talking about but not quite. It sounds
> > like you want caller() info available to the exception handler... but
> > isn't it?
>
>The basic problem is that the stack traceback at the ti
"David L. Nicol" wrote:
>
> sub openrecord{
> my $RecordFileName = &GetRecordFileName;
> TRYOPEN:
> open REC, "$RecordFileName" or throw "FILE-NO-OPEN";
> #work with the file
> ...
>
> return;
>
> my $probl
At 11:05 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
> >> Also a use (within main or if it can work lexically) that would mean
> >> die_if_exception_thrown. Would treat the main routine as if it were
> >> wrapped in a try block that doesn't catch
Graham Barr wrote:
>
> On Wed, Aug 16, 2000 at 10:19:53AM -0400, Chaim Frenkel wrote:
> >
> > I would say that outside of the try block all throws are caught if
> > at all by the wrapping try. So that throws propogate outward. Never
> > back within itself.
>
> Agreed.
Throws propagate *forward*
Jonathan Scott Duff wrote:
>
> I can almost see what you're talking about but not quite. It sounds
> like you want caller() info available to the exception handler... but
> isn't it?
The basic problem is that the stack traceback at the time of catching
is not the same as the stack traceback at
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > try { TryToFoo; }
> > catch { TryToHandleFailure; }
> > finally { TryToCleanUp; }
> > catch { throw "Can't cleanly Foo."; };
> >
> >In our production code we often add such blocks to major API entry
> >point
Peter Scott wrote:
>
> If that were so, even without the ignore() function, I could just say
>
> sub Exception::IO::throw { 'do nothing' }
>
> and kill it that way.
Right. Just like overriding core die. At that point you can
change the semantics in such a way as to turn your code in
Executive summary: I no longer want catch blocks to "daisy chain"
after a exception is thrown in a catch block. Thanks to everyone
who has helped me see the light on this.
Peter Scott wrote:
>
> At 01:16 AM 8/16/00 -0600, Tony Olekshy wrote:
> >
> > The proposed omnibus Exceptions RFC uses the f
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> >[snip]And the following output was generated:
> >
> > Exception
> >
> > $ = Try::throw('Exception') called from scott2.pm[8].
> > $ = main::pling('Test') called from scott2.pm[4].
> > $ = main::bar('Test') called from scott1.pl[1].
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
>> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>>
PS> 1. When an exception is thrown perl looks for the enclosing try block; if
PS> there is none then program death ensues.
>>
>>
At 10:56 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
> >> Perhaps, throw can carry a return value?
> >>
> >> throw {"return value"} $exception;
> >> If there is an active try/catch context the
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> Okay, :-) Got a better syntax? Would you want the option of
PS> throwing up n (> 1) levels?
I've seen the term SIGNAL vs. RAISE used.
I don't think we should. That gives the callee too much intimate
knowledge of the caller.
Lets keep
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
>> Perhaps, throw can carry a return value?
>>
>> throw {"return value"} $exception;
>> If there is an active try/catch context then the $exception would
>> be propogated, otherwise $@ would
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> =head2 eval/die remains perfectly workable
DLN> as "die" is a perfectly serviceable method or raising an exception.
Actually, die is pretty nasty. Modules can't use it.
Another mechanism that means, short circuit, but let the user
At 07:06 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
> >> There is one case to be considered, what if the try block wishes
> >> to avoid its own catch clauses, and start the unwinding with the
> >> uplevel try block.
>
>GB> Can you think of a ti
At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> 1. When an exception is thrown perl looks for the enclosing try block; if
>PS> there is none then program death ensues.
>
>Err, if there isn't one. Don't throw the exception. Stop process
At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
>Perhaps, throw can carry a return value?
>
> throw {"return value"} $exception;
>If there is an active try/catch context then the $exception would
>be propogated, otherwise $@ would get loaded with $exception and
>the return value would be t
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> 1. When an exception is thrown perl looks for the enclosing try block; if
PS> there is none then program death ensues.
Err, if there isn't one. Don't throw the exception. Stop processing but
don't throw. You are imposing a style on your
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>> There is one case to be considered, what if the try block wishes
>> to avoid its own catch clauses, and start the unwinding with the
>> uplevel try block.
GB> Can you think of a time you would want that ?
Here's one. If the catch blocks t
Perhaps, throw can carry a return value?
throw {"return value"} $exception;
If there is an active try/catch context then the $exception would
be propogated, otherwise $@ would get loaded with $exception and
the return value would be the specified value.
If not specified then it would be
> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
JSD> On Wed, Aug 16, 2000 at 12:36:42PM -0700, Peter Scott wrote:
>> If you use a switch statement and want implicit rethrow (and I do), then
>> your exception handler somehow has to look inside the switch to see if an
>> exception
or AUTOLOAD can be defined in terms of C
and overloaded that way, rather than being its own
kind of magic.
catch "AUTOLOAD-$classname-$polymorphicsignature" {...
Jonathan Scott Duff wrote:
>
> On Wed, Aug 16, 2000 at 12:15:30PM -0500, David L. Nicol wrote:
> > If "catch" can be def
=head2 eval/die remains perfectly workable
Perl5 has a perfectly agile exception handling method,
C, which syntax-checks at compile time and
returns the value of the value of the last expression
evaluated and sets the special error variables in cases
of errors.
We leave that alone, and use it f
Peter Scott wrote:
> >Only one of them needs to be right. As long as one is right,
> >there is no problem.
>
> Right, I was just pointing out that it's harder for people to divine which
> one we picked without recourse to the documentation.
Yes; unfortunately, this problem exists generally, es
At 04:59 PM 8/16/00 -0400, John Porter wrote:
> > > > What interpretation should be placed on statements in the try block
> > > > following a catch block?
> > >
> > >Whatever you want. I can think of three possibilities.
> >
> > That's the problem. Only one of them will be right.
>
>Only one of
At 03:40 PM 8/16/00 -0500, Jonathan Scott Duff wrote:
>Well, those of you writing "exception" RFCs be sure and include this
>example in there somewhere (if it's relevant to your RFC of course).
Done.
>I'm done thinking about exceptions now.
Some of us are hoping to do the same RSN :-)
--
Peter
Peter Scott wrote:
> Redirected to -errors to save a thousand eyeballs.
(I hope I'm on that list; please Cc me if not...)
> > > I find it quite intuitive :-)
> >
> >I note the smiley.
>
> It works without the smiley too.
Then you have the intuition of an Ascended Master.[1]
> > > What inte
Peter Scott wrote:
>
> qc?
A proposed form of in-line comment!
> > qc/try/ {
> > might_throw_E1_or_E2();
> > }
> > catch E1 {
> > might_throw_E2();
> > }
> > catch E2 {
> > # where did this E2 come from?
>
At 08:23 PM 8/16/00 +, Perl6 RFC Librarian wrote:
>=head3 Scoping problems
>
>Let's presume the example often cited, of wishing to close a file
>handle during the unwind, here's some C++ for that:
>
> FILE *handle;
> try {
> handle = fopen ( ... );
> ...
> }
> catch ( .
At 01:16 AM 8/16/00 -0600, Tony Olekshy wrote:
>The proposed omnibus Exceptions RFC uses the following three
>rules to guide it while unwinding through the clauses of a
>try statement.
Forgive me for eliding your explanation, but I find it a little opaque, and
it doesn't seem to explain how you
On Wed, Aug 16, 2000 at 12:52:07PM -0700, Peter Scott wrote:
> At 09:29 AM 8/16/00 -0500, Jonathan Scott Duff wrote:
> >Let me draw another picture (with "try" and "catch" this time):
> >
> > try {
> > # code that may cause exceptions
> > } catch {
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
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 119
=head1 ABSTRAC
At 12:00 AM 8/16/00 -0600, Tony Olekshy wrote:
>However, many people have broached topics such as conditional catch
>blocks (such as those based on the exception's isa relationships),
>multiple catch clauses with varying conditions, and post-finally
>catch blocks.
>
>I agree that we don't have a g
[Redirected to -errors]
At 11:23 AM 8/16/00 -0500, you wrote:
>On 15 Aug 2000, Perl6 RFC Librarian wrote:
>
> > =head2 Exceptions
> >
> > Exceptions are objects belonging to some C class. Cing
> > an exception creates the object; therefore, C above is just a
> > class name. C lets you subclass
At 11:49 AM 8/16/00 -0400, John Porter wrote:
>Glenn Linderman wrote:
> >
> > More seriously, I agree there is no need for a "try" keyword... it just
> > starts a block, which could just as well be any other block.
>
>This makes especially good sense if the catch{} is INSIDE the relevant
>block, r
Redirected to -errors to save a thousand eyeballs.
At 11:42 AM 8/16/00 -0400, John Porter wrote:
>Peter Scott wrote:
> > At 05:33 PM 8/15/00 -0400, John Porter wrote:
> > >The thing I don't like about C++/Java try/catch syntax is the way
> > >the blocks are daisychained. That is not intuitive to
At 09:29 AM 8/16/00 -0500, Jonathan Scott Duff wrote:
>Let me draw another picture (with "try" and "catch" this time):
>
> try {
> # code that may cause exceptions
> } catch { # catches ALL exceptions
> switch ($@->^_) {
>
On Wed, Aug 16, 2000 at 12:42:24PM -0700, Peter Scott wrote:
> At 10:16 AM 8/16/00 -0400, Chaim Frenkel wrote:
> >One issue that haven't seen addressed, is how to _not_ have exceptions.
> >
> >I want to use a core module (non-core can do anything they want) but
> >I'd like to write it in procedura
On Wed, Aug 16, 2000 at 12:36:42PM -0700, Peter Scott wrote:
> If you use a switch statement and want implicit rethrow (and I do), then
> your exception handler somehow has to look inside the switch to see if an
> exception was handled. Even if that's possible, it implies a level of
> incestuo
At 10:16 AM 8/16/00 -0400, Chaim Frenkel wrote:
>One issue that haven't seen addressed, is how to _not_ have exceptions.
>
>I want to use a core module (non-core can do anything they want) but
>I'd like to write it in procedural mode.
>
> try {
> $obj->method...
> }
At 10:08 AM 8/16/00 -0400, Chaim Frenkel wrote:
>What in the simple methodology combined with Damian's switch monster,
>is missing?
>
>I'll hazard a guess that, if the complex syntax goes in and if there
>is no semantic issue, -internals will likely convert the complex
>version internally to a swi
On Wed, Aug 16, 2000 at 11:49:03AM +0100, Graham Barr wrote:
> if any of the catch or finally throws, it is caught by a
> try {} block up the stack.
>
> Keep It Simple
What he said.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
At 02:01 PM 8/16/00 -0500, Jonathan Scott Duff wrote:
>On Wed, Aug 16, 2000 at 11:46:12AM -0700, Peter Scott wrote:
> > At 12:10 AM 8/16/00 -0500, Jonathan Scott Duff wrote:
> > >Why not have a special array that acts as an exception stack and each
> > >exception knows what file/line/whatever? Th
At 11:52 PM 8/15/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
> >> Please include the comments about global variables and action at a
> distance.
>
>PS> I'm sorry, my brain is fried. Can you spell out for me what you mean in
>PS> this context and I'll
On Wed, Aug 16, 2000 at 11:46:12AM -0700, Peter Scott wrote:
> At 12:10 AM 8/16/00 -0500, Jonathan Scott Duff wrote:
> >Why not have a special array that acts as an exception stack and each
> >exception knows what file/line/whatever? Then you can get both behaviors
> >with a simple for loop:
> >
At 12:10 AM 8/16/00 -0500, Jonathan Scott Duff wrote:
>Why not have a special array that acts as an exception stack and each
>exception knows what file/line/whatever? Then you can get both behaviors
>with a simple for loop:
>
> for (@PERL::EXCEPTIONS) {
> print $_->file, "\t",
At 07:40 PM 8/15/00 -0600, Tony Olekshy wrote:
> > > catch { ... }
> > >
> > > Invoked if unwinding. This is a post-finally catch,
> >
> > What's this for? If the finally block throws?
>
>Actually it's invoked if we're unwinding at that point, according to
>the definition of unwindin
-Original Message-
From: Barrie Slaymaker [mailto:[EMAIL PROTECTED]]
>[EMAIL PROTECTED] wrote:
>>
>> It basically allows the programmer to "try" a certain action and see what
the
>> effects are going to be (i.e. handle the exception) so that some action
can
>> then be taken based on the r
On Tue, 15 Aug 2000, Peter Scott wrote (with >):
[what is the purpose of having an explicit 'try']
> Well, for one, it makes it easier to see that a block is subject to
> exception handling if all you have to do is look at the beginning for 'try'
> rather than scan through it for a 'catch'.
My philosophy - do nothing unless its needed. Therefore there are no
rules, and I'll attempt to avoid creating any. I remain subscribed
to language-flow, and will redirect appropriate discussion to here.
Our deadline - August 29. It's actually a little tighter than that,
because on the morning
On Wed, Aug 16, 2000 at 10:19:53AM -0400, Chaim Frenkel wrote:
> I would say that outside of the try block all throws are caught if
> at all by the wrapping try. So that throws propogate outward. Never
> back within itself.
Agreed.
> There is one case to be considered, what if the try block wish
On Tue, Aug 15, 2000 at 11:59:50PM -0600, Tony Olekshy wrote:
> > for (@PERL::EXCEPTIONS) {
> > print $_->file, "\t", $_->line, "\n";
> > }
>
> Yawn. That's the way RFC 88 v1 does it. Check it out.
I've read it ... perhaps that's what even gave me the idea, but that
On Wed, Aug 16, 2000 at 10:11:32AM -0400, Chaim Frenkel wrote:
> > "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
>
> TO> Consider "finally" vs. "always". Always? Even if force majeur?
> TO> Finally simply means, "as the final act of the unwind processing".
>
> Am I missing something. I
On Tue, Aug 15, 2000 at 11:59:40PM -0600, Tony Olekshy wrote:
> Problem 1:
>
> In a large lexical scope, you have no preindication that intended
> non-local flow control is in effect until you read all the way to
> the end of the scope. The equivalent of your example in more human-
> friendly te
I would say that outside of the try block all throws are caught if
at all by the wrapping try. So that throws propogate outward. Never
back within itself.
There is one case to be considered, what if the try block wishes
to avoid its own catch clauses, and start the unwinding with the
uplevel try
> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
TO> Using exceptions for failure signalling is a more robust software
TO> engineering technique, but only if your exception handling mechanism
TO> doesn't "encourage" you to drop exceptions of the floor.
Is this proven or just an assertion o
> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
TO> Consider "finally" vs. "always". Always? Even if force majeur?
TO> Finally simply means, "as the final act of the unwind processing".
Am I missing something. I thought that the finally clause is executed
under normal and exceptional co
> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
TO> However, many people have broached topics such as conditional catch
TO> blocks (such as those based on the exception's isa relationships),
TO> multiple catch clauses with varying conditions, and post-finally
TO> catch blocks.
TO> I agree
On Wed, Aug 16, 2000 at 01:16:26AM -0600, Tony Olekshy wrote:
> try { } finally { } catch { }
I don not see ht epoint of this ?
IMO, it should be simple.
try { }
catch Class { }
catch { }
finally { }
If try throws it is caught by the catch blocks
finally is always run
if any of
On Tue, Aug 15, 2000 at 04:39:24PM -0700, Peter Scott wrote:
> >PRL> =head2 Exception classes - ignoring
> >
> >PRL> Note that we could also make it possible to selectively or globally
> >ignore
> >PRL> exceptions, so that perl continues executing the line after the C
> >PRL> statement. Just imp
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Tue, Aug 15, 2000 at 04:12:17PM -0700, Peter Scott wrote:
> > >Would someone please enlighten me as to the purpose of an explicit "try."
> >
> > Well, for one, it makes it easier to see that a block is subject to
> > exception handling if all
[EMAIL PROTECTED] wrote:
>
> On Tue, Aug 15, 2000 at 09:27:23PM -0700, Ask Bjoern Hansen wrote:
> >LIST: perl6-language-objects
> >CHAIR: Nathan Wiger <[EMAIL PROTECTED]>
> >MISSION:Develop RFCs related to objects and OO programming in
> >Perl, possibly
The proposed omnibus Exceptions RFC uses the following three
rules to guide it while unwinding through the clauses of a
try statement.
Rule 1: Uncaught Exceptions Propagate
At the end of the try statement, you are going to continue
unwinding up another level if *anything* threw, *unless*
64 matches
Mail list logo
