Originally, you repeatedly referred to an error; now you seem to have changed that to a warning

Sorry for the confusion.

My module throws warnings and errors - it generates both by printing to STDERR

The question wasn't so much about dealing with warnings and errors but more about suppressing the warnings during the output from the tests. Although, this is one of those situations where I didn't really know exactly what I wanted to know until I had asked the question and got lots of helpful comments. The original question asked about suppressing this line

Stripe Webhook Error: Invalid Stripe Signature
[download]

My module throws warnings and errors - it generates both by printing to STDERR

No, it does not, at least not in version 1.11 as published on CPAN. It throws no errors and no warnings. It just prints to STDERR, although it looks like it should alternatively call a custom function. (See below the line.)

To throw errors, call die. To throw warnings, call warn. To suppress "at <filename> line <number>", append a newline to the message. To get a stack trace, see Carp.

---

I think this does not do what you want:

# Returns error if last operation failed
sub error {
    my $self = shift;
    return $self->{'error'};
}

# ...

sub _error {
    my ($self, $message) = @_;
     
    $self->{'error'} = $message;           # <--(1)
    if (defined &{$self->{'error'}}) {     # <--(2)
        &{$self->{'error'}}($message);     # <--(3)
    } else {
        STDERR->print("Stripe Webhook Error: $message\n");
    }
}
[download]

At (1), you store the error message in $self->{'error'}, much like you do in sub error. At (2), you check if $self->{'error'} that you just have overwritten contains an error callback function which you try to call at (3). Unless $message is set to a valid function name, this code will always print to STDERR.

I think what you wanted to implement were two attributes, one for the error message (e.g. $self->{'errorMessage'}) and one for an error handler (e.g. $self->{'errorHandler'}).

But what you really want is just a proper exception. Don't re-implement the wheel, don't mess up your object with all of that error handling nonsense. If something goes wrong, just call die and leave it to the user if (s)he wants to use a plain old eval, something like Try::Tiny, the fancy new try-catch-finally, or just let the program die. Same for warnings. Just call warn and let the user decide if warnings should cause some action or should be ignored.

If you want fancy stack traces, use Carp instead of plain die/warn.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

To throw errors, call die. To throw warnings, call warn

The next version of the module will call warn so I can trap the output with Test::Warn

However, I will not call die. I find it frustrating when modules die. Especially modules where there is a reasonable chance that there may be an error such as when they are dealing with a network or rely on the user to provide input in a particular format such as valid JSON - I attempt not to inflict that frustration on others.