At 11:03 AM 8/21/00 -0400, Chaim Frenkel wrote:
>Those rule are hard to read. I've tried reading them quite a few times
>and I have trouble understanding them. I can't tell if the rules are
>complex or it simply needs to be reworked. If it is complex then I
>don't think this is the right approach.
Those rule are hard to read. I've tried reading them quite a few times
and I have trouble understanding them. I can't tell if the rules are
complex or it simply needs to be reworked. If it is complex then I
don't think this is the right approach. The rules should be simple.
As for legacy. I stron
> >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
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
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
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,
=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
