On Thu, 10 Aug 2000, Perl6 RFC Librarian wrote:
> All perl generated errors should have a unique identity. So that
> changes in the text should not cause breakage in code.
>
Good idea. A lot of programs do this. It could make it easier to
handle error callbacks. (If you ever get a 'no space left on device'
type error, call remove_my_entire_directory_tree();)
What about compartmentalization of Perl space and user space, though,
when dealing with use of the actual mechanisms? Gentlemen's
agreement? User space caveat scriptor?
> =head1 DESCRIPTION
>
> Currently many programs handle error returns by examining the text of
> the error returned in $@. This makes changes in the text of the error
> message, an issue for the backwards compatibility police.
>
> An added benefit, depending upon the actual method of identifing
> errors selected could be a classification scheme for errors.
>
> =head1 IMPLEMENTATION
>
> Each unique identifier once assigned as part of a stable release
> of perl will be guarenteed never to be changed, or if the error
> text is removed, never to be reused.
>
> =head2 Encodings
>
> I have listed some possiblities. But none of these are ideal.
>
> =head3 A unique number
>
> Each error message will be assigned a unique number. The number
> could be made accessible via the $@ in a numeric context.
This would, at least, parallel $!'s magic. Or new pair value, I
suppose. (RFC - Request From Conway, Required For Conway :-)
> =item As a floating point number
>
> The integer part would be the actual identifier. The fractional
> part could encode some classification scheme.
Depending on whether you wanted an error to meet multiple
classifications, it may make more sense to switch the two.
CLASS.ERROR
This may make it easier for users to register their own errors under
pre-existing classes.
Another idea would be two shorts, one for each. (Where you could
either handle numbers or bitmaps.)
--
Bryan C. Warnock
([EMAIL PROTECTED])
