"Brust, Corwin" wrote:
>
> Peter Scott wrote:
> >
> > I think it would be best to supply a reference. This is a
> > mammoth RFC already and it will be decided on by people who
> > very well know what exception handling is; their reading time
> > is at a premium.
>
> Decided on, yes, but having th
Glenn Linderman wrote:
>
> So that was one thing I tried to do in RFC 119: it discusses
> only throwing and handling exceptions. It leaves open what is
> thrown. It allows for simple exceptions in simple programs to
> use simple mechanisms (throw a scalar); it allows for complex
> but non-OO e
As currently promulgated, catch "Foo" {} will always catch,
because "Foo" is true. Will this cause confusion for developers
who meant to say catch Foo {}? And what happens when someone
says catch "Foo", "Bar" {}?
We can't just say that catch Foo {} and catch "Foo" {} are the
same thing, or that
Peter Scott wrote:
>
> I am willing to withdraw RFC 63 if the following parts are
> included somewhere in RFC 88 in this or equivalent language:
I should like to note that I would like Peter to be described
as a co-author in RFC 88, whether or not RFC 63 is withdrawn.
That is, with his permissio
> >We write a lot of simple throws, most of which would look
> >like this with the new mechanism as proposed so far:
> >
> > throw Error_DB "ABC.1234: Message about what went wrong.";
> >
> > Without the techniques and hooks I've described in 88v2d2,
> > I'd have to write the following, which has
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > "An exception is not necessarily an error.\n" x 3;
>
> Note that 'error' is a vague term for which you have a specific
> meaning in mind here; be sure to give that definition where it's
> important.
How 'bout something like, "an exception r
At 08:01 PM 8/18/00 -0600, Tony Olekshy wrote:
>RFC 88 is discussing making errors into exceptions. I strongly
>don't think we should attempt the converse, that is, making
>exceptions into errors.
>
> "An exception is not necessarily an error.\n" x 3;
Note that 'error' is a vague term for wh
RFC 88 is discussing making errors into exceptions. I strongly
don't think we should attempt the converse, that is, making
exceptions into errors.
"An exception is not necessarily an error.\n" x 3;
That's why RFC 88 defines both Exception and Error classes, the
latter of which inherits from
I'm rejigging RFC 88 so that not only does $@ refer to the
current exception, but @@ refers to the exception stack. This
moves all the link handling stuff (such as link and any) out
of the Exception class and into the handling mechanism itself.
So, now you can say:
catch grep { $_->isa
-Original Message-
From: Peter Scott [mailto:[EMAIL PROTECTED]]
or even the cooler
throw Exception::MyDB "ABC.1234" => "Some message about what went
wrong"
O! I like that! I guess I might come to love C after all.
I think it would be best to supply a reference. This
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
I am willing to withdraw RFC 63 if the following parts are included
somewhere in RFC 88 in this or equivalent language:
"Note that C is a keyword, not a function. This is solely so that
a C<;> is not needed at the end of the last block, since so many people
are bound to think it shouldn't be th
At 06:04 AM 8/18/00 -0600, Tony Olekshy wrote:
> exception 'Error::DB::Foo';
>
> Makes Error::DB::Foo into a class that inherits from the built-in
> Exception class.
>
> If the given name matches /::/, something like this happens:
>
> @Error::DB::Foo::ISA = 'Error::DB';
Hmm,
At 11:02 PM 8/17/00 -0600, Tony Olekshy wrote:
> > Note: I used to favor $_[0] for the exception, but I'm being
> > won over to $@. As long as it doesn't cause problems with
> > external interfaces. Might mention the $_[0] idea in a
> > footnote.
>
>Done.
Um, see last message. There's a lot to
At 10:33 AM 8/18/00 -0500, Brust, Corwin wrote:
>Hmm this gets me thinking:
>In the context of a catch block, if could @_ contain the exception stack,
>starting with the current exception, could C be modified to act of @_
>if called in void context with no arguments?
I like the idea of passing th
Hmm this gets me thinking:
-Original Message-
From: Tony Olekshy [mailto:[EMAIL PROTECTED]]
Or, with try/catch...
sub openrecord
{
for (my $attempt = 0; $attempt < 5; ++$attempt) {
my $fileName = &GetRecordFileName;
try { open REC, $fileName; }
=head1 TITLE
Structured Exception Handling Mechanism
=head1 VERSION
Maintainer: Tony Olekshy <[EMAIL PROTECTED]>
Date: 18 Aug 2000
Version: 2 (Draft 2)
Mailing List: [EMAIL PROTECTED]
Number: 88
=head1 DRAFT STATUS
Areas of development of this document which are not ye
17 matches
Mail list logo
