Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Sun, Aug 13, 2000 at 07:27:47PM -0700, Peter Scott wrote:
> > At 12:22 PM 8/12/00 -0500, Jonathan Scott Duff wrote:
> > Pretty much. It screams O-O for these reasons:
> >
> > An exception is an 'error'. That's already a vague concept.
> >
>
Jonathan Scott Duff wrote:
>
> I have only a passing familiarity with exception handling and have
> only used it in "toy" programs. I'm just trying to wrap my mind
> around the whys and wherefors. I understand how it works, but not
> why it works the way it does, any references to exception han
Jonathan Scott Duff wrote:
>
> On Sun, Aug 13, 2000 at 07:27:47PM -0700, Peter Scott wrote:
> >
> > An error has text associated with it, but also a bunch of other
> > attributes.
>
> So it's a structured data type... where does OOP come into play?
1. It allows you to *extend* the base type wi
Dan Sugalski wrote:
>
> David L. Nicol wrote:
>
> > Why not call them throw and catch, like everywhere else,
> > and reccomend them over die?
>
> "If everyone else was jumping off a bridge, would you jump too?"
If they're jumping off because it's on fire at both ends, I might ;-)
> What everyone
Peter Scott wrote:
>
> David L. Nicol wrote:
>
> >Further discussion in the thread discussed the idea of returning
> >to the point of throwing, as the routine noting the error might
> >be supposed to ignore this error, the author of this comment
> >(Bennett Todd?) implied that that is how throwi
Peter Scott wrote:
>
> An exception is an 'error'. That's already a vague concept.
I'll say it's vague. There are certainly uses for an exception to
trigger non-local success, not an error at all. In fact, there are
whole programming techniques based on such uses. Just because most
of us usu
Tony Olekshy <[EMAIL PROTECTED]> writes:
> Peter Scott wrote:
> >
> > An exception is an 'error'. That's already a vague concept.
>
> I'll say it's vague. There are certainly uses for an exception to
> trigger non-local success, not an error at all. In fact, there are
> whole programming tec
On Mon, Aug 14, 2000 at 04:16:42AM -0600, Tony Olekshy wrote:
> Peter Scott wrote:
> >
> > David L. Nicol wrote:
> >
> > >Further discussion in the thread discussed the idea of returning
> > >to the point of throwing, as the routine noting the error might
> > >be supposed to ignore this error, t
Piers Cawley wrote:
>
> Tony Olekshy writes:
>
> > Peter Scott wrote:
> > >
> > > An exception is an 'error'. That's already a vague concept.
> >
> > I'll say it's vague. There are certainly uses for an exception to
> > trigger non-local success, not an error at all. In fact, there are
> > wh
Graham Barr wrote:
>
> Tony Olekshy wrote:
> >
> > I agree with Peter: use a try with an empty catch.
>
> That depends on how you think about things.
>
> Many people seem to be coming from the though of "I want to
> catch these exceptions" where-as the current perl-like way
> to do this is "I w
Tony Olekshy wrote:
> Just be sure to arrange to handle exceptions while handling
> exceptions.
Are you saying that the try-catch proposal automatically
handles exceptions thrown in catch and finally blocks?
That's an interesting idea. Java, C++, and Delphi don't do
that for you. They expect the
On Mon, Aug 14, 2000 at 04:09:41AM -0600, Tony Olekshy wrote:
> $@->CanFoo is an example of semantics that determines whether or
> not the exception is caught; stringification may be an example
> of semantics that comes into play when an exception is caught.
Ah, this is why I started asking I gue
On Sun, Aug 13, 2000 at 05:25:01PM -0600, Tony Olekshy wrote:
> RFC 88 allows any Perl datum to be used as an exception. RFC 96
> proposed a standard exception object base class. Given such a
> base class, exception handling can do fancier things based on
> instances of derivatives of the base c
On Sun, Aug 13, 2000 at 10:51:24PM -0700, Peter Scott wrote:
> Could be. I'd be interested in seeing non-OOP proposals that do what I
> want exceptions to do, I have a hard time imagining one.
Well, what is it that you want exceptions to do?
> >What does it mean for an exception to have semant
From: "Peter Scott" <[EMAIL PROTECTED]>
Sent: Sunday, August 13, 2000 10:35 PM
> try {
># fragile code which doesn't call any subroutines that might die
># and doesn't include any other try blocks
> } catch {
># No code at all
> }
Well, I don't really like that solution. It's exactly
Let us get away from the globals as much as we can. This can easily
(I think) be taken care of by having the _exception_ itself have the
uncaught handler
$exception = Exception::whatever->new
$exception->uncaught_handler = CODEREF
> "JM" == James Mastros <[EMAIL PROTECTED]>
At 05:22 AM 8/14/00 -0600, Tony Olekshy wrote:
>Graham Barr wrote:
> >
> > Tony Olekshy wrote:
> > >
> > > I agree with Peter: use a try with an empty catch.
> >
> > That depends on how you think about things.
> >
> > Many people seem to be coming from the though of "I want to
> > catch these exce
At 08:13 AM 8/14/00 -0700, Evan Howarth wrote:
>Tony Olekshy wrote:
> > Just be sure to arrange to handle exceptions while handling
> > exceptions.
>
>Are you saying that the try-catch proposal automatically
>handles exceptions thrown in catch and finally blocks?
Well this is debatable, but IMHO
At 10:01 AM 8/14/00 -0400, Steve Simmons wrote:
> 80 - Builtins should permit try/throw/catch as per Java/fatalpm
> style (Peter Scott).
Almost. It's saying that builtin exceptions should be objects with
specific attributes iff a try/throw/catch mechanism is also approved.
>I'd like
James Mastros wrote:
> My proposal is:
> $Exceptiononuncaught = CODEREF.
>
> The value of onuncaught should follow isa if it doesn't exist.
>
This would be right at home in the pre-RFC %ISA hash of
objecty stuff $ISA{ONUNCAUGHT} instead of a global. Creating
$whatever::ISA{O
On Mon, Aug 14, 2000 at 06:17:02PM -0400, Chaim Frenkel wrote:
> Let us get away from the globals as much as we can. This can easily
> (I think) be taken care of by having the _exception_ itself have the
> uncaught handler
>
> $exception = Exception::whatever->new
> $exception->uncaug
> "JM" == James Mastros <[EMAIL PROTECTED]> writes:
JM> On Mon, Aug 14, 2000 at 06:17:02PM -0400, Chaim Frenkel wrote:
>> Let us get away from the globals as much as we can. This can easily
>> (I think) be taken care of by having the _exception_ itself have the
>> uncaught handler
>>
>> $exc
I think folks are forgetting that there are more than one client for
any class. Global settings should be restricted to a single setter.
The only logical single setter is main. All other clients should
be using something local.
Another reason to avoid globals, is we are designing perl6 to be thre
I'm missing the problem. The throw for whatever reason from c2 should
end up in c1. No?
try { # t1
try { # t2
# something thrown
}
catch { # c2
# something unexpected thown
At 10:02 PM 8/14/00 -0400, Chaim Frenkel wrote:
>I'm missing the problem. The throw for whatever reason from c2 should
>end up in c1. No?
>
>
> try { # t1
>
> try { # t2
> # something thrown
> }
> catch { #
Jonathan Scott Duff wrote:
>
> On Mon, Aug 14, 2000 at 04:09:41AM -0600, Tony Olekshy wrote:
> >
> > $@->CanFoo is an example of semantics that determines whether or
> > not the exception is caught; stringification may be an example
> > of semantics that comes into play when an exception is caugh
Jonathan Scott Duff wrote:
>
> On Sun, Aug 13, 2000 at 05:25:01PM -0600, Tony Olekshy wrote:
> >
> > RFC 88 allows any Perl datum to be used as an exception. RFC 96
> > proposed a standard exception object base class. Given such a
> > base class, exception handling can do fancier things based o
Evan Howarth wrote:
>
> Tony Olekshy wrote:
> >
> > Just be sure to arrange to handle exceptions while handling
> > exceptions.
>
> Are you saying that the try-catch proposal automatically
> handles exceptions thrown in catch and finally blocks?
Yes.
> That's an interesting idea. Java, C++, an
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > When you want the first one, use try + catch.
> >
> > When you want the second one, use eval, then manipulate $@.
> > Just be sure to arrange to handle exceptions while handling
> > exceptions.
>
> Erk, people shouldn't have to use such radicall
Peter Scott wrote:
>
> If anyone suggests that
>
> try { }
> catch Exception::Foo, Exception::Bar { ... }
> catch { exception thrown here causes it to
> start going through catch blocks again }
>
> then I'm afraid I'm going to have to turn to drink.
Agreed. Ho
Chaim Frenkel wrote:
>
> The throw for whatever reason from c2 should end up in c1.
>
> try { # t1
>
> try { # t2
> # something thrown
> }
> catch { # c2
> # something unexpected thown
Peter Scott wrote:
>
> I'll keep modifying my RFCs with the great feedback and ideas that
> are popping up. If my RFC 63 gets close enough to RFC 88 in this
> process that I see no impact from merging them - as seems to be
> happening - I'll certainly propose to Tony that we merge them as
> co-au
Tony Olekshy wrote:
>
> Jonathan Scott Duff wrote:
> > Some people were proposing
> > a try/catch like the following:
> >
> > try { }
> > catch SomeException { }
> > catch SomeOtherException { }
> > finally { }
> >
> > which seems to only catch exceptions based on
At 08:56 PM 8/14/00 -0600, Tony Olekshy wrote:
>consider this:
>
> try { may_throw_1; }
> catch { may_throw_2; }
> catch { may_throw_3; }
> finally { may_throw_4; }
That's either a syntax error or a no-op. More likely the latter. If you
have multiple catch blocks which
What if we implemented something like the following?
exception 'MyException';
This is like use Exception 'MyException'; but since
the Exception base class needs to be available to the
Perl guts, it probably won't be a module per se.
try { ... throw MyException->n
This seems like a good idea, to me.
-Corwin
From: Steve Simmons [mailto:[EMAIL PROTECTED]]
>IMHO trading six RFCs for two will greatly improve the chance of passing.
36 matches
Mail list logo
