Front page | perl.perl5.porters |
Postings from June 2022
> On Jun 3, 2022, at 16:22, Neil Bowers <neilb@neilb.org> wrote:
>
> Hi Felipe,
>
> We discussed part 1 – improving the wording of the wide character messages – and agreed that we’d like to see this, and also that it doesn’t need to go via an RFC.
>
> So we encourage you to propose some wording on p5p, and then submit a PR.
>
> We’ve marked your Pre-RFC as "N/A" in the tracker. You could start a separate Pre-RFC thread if you want to raise the idea of codes for warnings and error messages.
Some further thoughts:
Changing the wording of the error message as it stands risks breaking preexisting applications. So it seems imprudent to do it without a feature/pragma.
Even that aside, the broader issue is that Perl’s warnings & error messages can gainfully be made more helpful. Making one change specifically for wide-character warnings seems less-good than looking at whether we might be able to improve the whole lot.
And so, here’s a proposal:
-----
# This tells Perl to prefix all of its “native” warnings & exceptions with a
# “help code”. It will also cause various tweaks to the messages.
#
use feature 'helpcodes';
# This normally warns `Wide character in print …`.
# Under the helpcodes feature it will instead warn (note the updated text):
#
# HELP-WIDEOUT: Wide character in print (remember to encode!) …`
#
print "\x{100}";
# This normally dies `Illegal division by zero …`.
# Under the helpcodes feature it will instead die thus:
#
# HELP-DIVZERO: Illegal division by zero …`
#
my $foo = 9 / 0;
-----
The idea is simple: apply the familiar pattern of POSIX error names (ENOENT, EPERM, etc.) to Perl. These will be easily searchable in search engines, and we can list them in something like perlhelpcodes.pod.
Thoughts?
-FG
Thread Previous
|
Thread Next