Peter Scott wrote:
>
> I still think the explanation can be made simpler with fewer
> forward references. I'll have another try: [snip, but save]
>
> I note that under these rules it would be possible to have
> "try { ... } finally { }" with no catch blocks. I guess
> that's okay.
Have I got n
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > trap { $@->{message} =~ /divide by 0/ } catch { ... }
>
> I don't think you need another keyword here. Just support an
> expression argument to catch and you can do
>
> catch $@->{message} =~ /divide by 0/ { ... }
>
> If it needs t
Glenn Linderman wrote:
>
> "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.
>
> But none of the currently proposed exception handl
"David L. Nicol" wrote:
>
> sub openrecord{
> my $counter, $RFN;
> while( 1){
> -r ($RFN = &GetRecordFileName) and last
> ++$counter > 6 and return undef;
> };
> open REC, "$RFN";
> ...
> }
Depend
Peter Scott wrote:
> Tony Olekshy wrote:
> >Peter Scott wrote:
> > > Tony Olekshy wrote:
> > > >
> > > > try { TryToFoo; }
> > > > catch { TryToHandle; }
> > > > finally { TryToCleanUp; }
> > > > catch { throw "Can't cleanly Foo."; };
> > > >
> > > > In our
At 05:18 PM 8/17/00 -0500, David L. Nicol wrote:
>Peter Scott wrote:
>
> > >Maybe $! becomes an alias for anything that gets thrown
> >
> > Actually it looks like $@ is doing that at the moment. *Confused*
>
>Make them all writable, then we can make user-defined errors seem
>to be whatever we w
At 09:13 PM 8/16/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > Tony Olekshy wrote:
> > >
> > > try { TryToFoo; }
> > > catch { TryToHandleFailure; }
> > > finally { TryToCleanUp; }
> > > catch { throw "Can't cleanly Foo."; };
> > >
> > >In our pr
At 09:12 PM 8/16/00 -0600, Tony Olekshy wrote:
>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.
I'm not sure what you mean by "daisy chain". I have been taking it to mean
Peter Scott wrote:
> >Maybe $! becomes an alias for anything that gets thrown
>
> Actually it looks like $@ is doing that at the moment. *Confused*
Make them all writable, then we can make user-defined errors seem
to be whatever we want.
Or leave them the hell alone and introduce a new var
At 12:51 PM 8/17/00 -0700, Damien Neil wrote:
>Hmm. It just occurred to me that you could combine your idea with
>exceptions quite nicely: All core functions throw exceptions on
>error, but only when called in a void context. (As well as, perhaps,
>when a given pragma is in effect.) This way, o
At 06:10 AM 8/17/00 -0600, Tony Olekshy wrote:
>catch "Error::DB" { ... }
>
> catch [ "Error::DB", "Error:IO" ] { ... }
>
> trap { $@->{message} =~ /divide by 0/ } catch { ... }
I don't think you need another keyword here. Just support an expression
argument to catch and you can do
I had been thinking of some special goto labels, things like
BEGINNING and END which would signify the beginning and end of the
block enclosing the throw; perhaps every SCOPE object could have
these labels refered to in terms of them. inside a C we
need to have access to a lot of internal flow d
"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
At 10:11 AM 8/17/00 -0700, Larry Wall wrote:
>Peter Scott writes:
>: Do we want to come up with any modifications to the scope of $! (I'm not
>: talking about the dual string-number nature)? I've occasionally been
>: flummoxed by looking at it when there hadn't really been an error (but it's
>: s
Graham Barr wrote:
>
> 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 s
Peter Scott writes:
: Do we want to come up with any modifications to the scope of $! (I'm not
: talking about the dual string-number nature)? I've occasionally been
: flummoxed by looking at it when there hadn't really been an error (but it's
: set anyway, randomly it seems); or calling some
On Thu, 17 Aug 2000, Tony Olekshy wrote:
> trace
>
> A listref containing a snapshot of the call-stack as at the time
> the exception is first raised. The array contains hashes (one
> per call stack level), each containing one key value pair for
> each snapshot value at that lev
=head1 TITLE
Structured Exception Handling Mechanism
=head1 VERSION
Maintainer: Tony Olekshy <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 2 (Draft 1)
Mailing List: [EMAIL PROTECTED]
Number: 88
=head1 ABSTRACT
This RFC describes a collection of changes and additions t
18 matches
Mail list logo
