develooper Front page | perl.perl5.porters | Postings from June 2022

Re: Pre-RFC: “helpcodes” feature

Thread Previous | Thread Next
Felipe Gasper
June 8, 2022 12:18
Re: Pre-RFC: “helpcodes” feature
Message ID:

> On Jun 8, 2022, at 07:45, Karl Williamson <> wrote:
> On 6/8/22 00:02, Ovid wrote:
>> On Tue, Jun 7, 2022 at 6:56 PM Felipe Gasper < <>> wrote:
>>    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.
>> This is true. It also kills me every time I see that. One of the (many) beautiful things of throwing exceptions is being able to test the class of the object. If people do that, changing the wording of the error message isn't that big of a deal (and makes it safe to localize, provide additional information about the error, etc.)
>> I really wish warnings were the same: objects that stringify intelligently. If your application or tests trap it, they use the class to figure out the type of warning it is and the actual text is for the poor humans writing the code. Relying in arbitrary text is fragile code. /Providing/ arbitrary text and nothing else is proving fragile code. I wish we didn't do that.
>> So many of these "we can't change the text" discussions would simply go away.
>> /end rant
> +1

+1 from me, too.

I didn’t propose core exception objects (or warnings) because that seems a dramatic increase in scope, but I do think core exceptions would be a wonderful addition to Perl, and the most ideal way to solve this problem.

If those core error objects were overloaded to stringify, wouldn’t that preserve the vast majority of applications that do string-matching on Perl-thrown errors/warnings?

try {
    my $foo = 9 / 0;
catch ($e) {
    if ($e =~ /zero/) { .. }

The pattern-match against /zero/ would still pass in the above scenario if $e were an instance of, e.g., Error::Perl::DivByZero, if that class defined a stringification overload to the old text.

Of course, applications that check explicitly for ref or blessed would break. I think such breakage would be unlikely in production, though, if it’s behind a feature (cf. my just-now-sent response to Dan Book).


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About