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, suppose they haven't done "exception 'Error::DB'"? Should it create
that for them?
> catch Error::DB { ... }
>
> When catch is follwed by a class name, it is syntactic sugar
> for:
>
> catch $@->isa($string) { ... }
>
> catch Error::DB, Error:IO { ... }
>
> When catch is follwed by a comma-seperated list of class names,
> it is syntactic sugar for:
>
> catch grep { $@->isa($_) } @list { ... }
There is no difference between these two cases.
>Exceptions raised by the guts of Perl are envisoned by this RFC to
>all be instances of classes that inherit from Error.
That's orthogonal to this RFC, though. You can propose an exception
handling mechanism without requiring that the core use it; that's what RFC
80 is for.
> Instances of
>the actual Error class itself are reserved for so-called anonymous
>exceptions, for those cases in which one more or less just wants to
>say C<throw Error "My message.">, without a lot of extra tokens, and
>without getting into higher levels of the taxonomy of exceptions.
This is what the user would get by just die-ing. Let's not use
'anonymous'; it makes people think of anonymous arrays, hashes, &
subroutines, and hence confused.
>On the other hand, new exception classes that inherit directly from
>Exception, as opposed to from Error, are assumed to be asking for
>more light-weight functionality. The intent of this RFC is to
>provide a place (Exception) in which methods can be stubbed in for
>the functionality required by Errors, so that when they are
>overridden by Error they work as expected, but when inherited by
>other derivatives of Exception, this error-functionality is avoided
>and does not otherwise interfer with the requirements of light-
>weight exception handling protocols. The stack-traceback at throw-
>time instance variable, for example, probably doesn't make much
>sense when one is throwing success, not failure.
>
>Although this Exception/Error partitioning has not yet been taken
>advantage of in this RFC, it does provide a good place to help
>make exception handling and error handling into almost the same
>thing, without adversely affecting the functionality of either.
I think this is unnecessary (and we should shorten the RFC so that more
people will read it). Leave the whole Error class out; that's something
separate, as I've said. I can make RFC 80 say what you want system
exceptions to be.
>=head3 Instance Variables
>
>The built-in Exception class reserves all instance variable
>and method names matching C</^[_a-z]/>. The following instance
>variables are defined.
>
>tag
>severity
>message
>debug
>object
>sysmsg
Why sysmsg? Why wouldn't a core exception use message? Why should someone
have to look at both?
>trace
>link
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.
--
Peter Scott
Pacific Systems Design Technologies
