=head1 TITLE
messages.rfc - An RFC to discussing the wisdom of allowing run time error
and warning messages to be modified at run time
=head1 VERSION
Maintainer: Corwin Brust <[EMAIL PROTECTED]>
Date: 1 Aug 2000
Version: 1
Mailing List: perl6-language
Number: ???
=head1 ABSTRACT
I'm probably wrong in this, but I rather think this one's explains it self.
I want perl's error (and warning) messages to be specific to each program I
write.
=head1 DESCRIPTION
I have, and I cannot assume I am alone in this, spent a fair amount of time
creating subroutines which trap various error responses from Perl, only to
turn right around and 'die' with an error message of my own, differing only
in the text shown when the program terminates.
Wouldn't it be great if we could just reword the existing error messages on
a per-script basis to be relevant to that program, and let Perl's normal
error handling mechanism do the work of presenting the user with the bad
news.
=head1 IMPLEMENTATION
It seems, as of this writing, that the means for accessing Perl internal
variables will not be as it has been.
Any method of allowing for program writer defined messages would have to be
closely time to whatever new mechanism we find agreeable. But...
$perl::core::err{TYPE_MISMATCH} = {
fatal => 1,
handler => sub {
my $arg = shift;
my $func = shift;
my $correct_type =
shift;
my $sent_type = shift;
my $prog = shift;
my $line = shift;
my $near = shift;
CORE::die(qq[Type of
$arg to $func must be $correct_type (not $sent_type) at $prog line $line,
$near\n]);
},
}
Where CORE::die is able to look for a true value in
$perl::core::err{TYPE_MISMATCH}->{fatal} and either die or issue a warning
as appropriate.
And, yeah, I'm sure there's a B<better> way to implement this. I hope,
however, that I have shown such a thing can be done.
=head1 REFERENCES
=cut
-----Original Message-----
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 01, 2000 3:48 PM
To: Brust, Corwin; 'Steve Simmons'; Perl6 Language Changes
Subject: RE: Removing/fixing $[line noise here] variables
At 03:53 PM 8/1/00 -0500, Brust, Corwin wrote:
>Could this then also give the programer control over the content of
>error/warning messages produced by Perl at runtime?
That's feasable. It'd be a performance hit, but I can't picture this really
being a performance-critical area... :)
Put together an RFC for it. (Soon!) This is a language topic, but it will
impact internals a touch, and I'd like to get as many of the "impact
internals" things spec'd out as soon as possible. Even if the final form
differs, it's easier to modify a capability than bolt it on after. (cf
perl5 & threads...)
>-----Original Message-----
>From: Steve Simmons [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, August 01, 2000 3:37 PM
>To: Perl6 Language Changes
>Subject: Removing/fixing $[line noise here] variables
>
>
>For deprecation, we should have a %PERL_DEPRECATED{mod}{thing} hash as
>well. `mod' is `CORE', `FORMATS', etc, as above. A value of 0 means the
>function is actually gone, 1 means it's disappearing next major release,
>2 mean next minor, etc. The programmer can control what happens when
>the feature is used by setting a %PERL_DEPRECATED{mod}{warning} value
>to 0 for default, 1 for once, 2 for never, etc, etc.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
