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 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: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
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
Kai Henningsen wrote:
>
> Tony Olekshy wrote:
>
> > What if we implemented something like the following?
>
> Seems that the basic unwinder is
>
> > except { ... } => catch { ... }
>
> and everything else can be written in terms of this:
>
> > catch { ... }
>
> except { 1 } => catch
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:
>
> 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].
> "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
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
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
[EMAIL PROTECTED] (Tony Olekshy) wrote on 15.08.00 in
<[EMAIL PROTECTED]>:
> What if we implemented something like the following?
Seems that the basic unwinder is
> except { ... } => catch { ... }
and everything else can be written in terms of this:
> catch { ... }
except { 1 } =>
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
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
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
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
> "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
I have moved this to [EMAIL PROTECTED]
Chaim Frenkel wrote:
>
> Sorry, I keep reading [except], even with your explanation, as
> "ignore this [catch]". A more positive word would be better.
I take your point. Patches are welcome ;-)
> I haven't seen a good reason that it should be any more co
Jonathan Scott Duff wrote:
>
> On Tue, Aug 15, 2000 at 05:14:56PM -0700, Peter Scott wrote:
> >
> > I want: exceptions to contain 'file' and 'line' attributes which
> > are arrays that get a location pushed on every time an exception
> > bubbles up through a scoping level.
>
> Why not have a spe
On Tue, Aug 15, 2000 at 10:52:02PM -0400, Chaim Frenkel wrote:
> Why does all the unwinding stuff have to be there? Let $@ exist in
> the always block the iff $@ is defined then you are unwinding and
> do your wishes. Otherwise you are just falling out of the BLOCK.
>
> Why all the extra syntax?
On Tue, Aug 15, 2000 at 05:14:56PM -0700, Peter Scott wrote:
> You want: while handling an exception, throwing another exception pushes
> the first one onto a stack which could be reported en masse when the coup
> de gras arrives. Like VMS error cascading. You do this with a _link
> attribute
22 matches
Mail list logo