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

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.

However, I will not call die. I find it frustrating when modules die.

WTF?

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

So, what should your module do when being fed with garbage instead of sane input? Pretend nothing evil has happened? Invent other, sane input? Ask for more garbage to be stuffed into your module?

What should it do if the network goes down or a required service somewhere on the internet can't be reached? Wait for the heat death of the universe?

What should it do if the system runs out of disk space? Gain root privileges and recursively delete all files not used in the last three years?

I attempt not to inflict that frustration on others.

Get over it. There is nothing to be frustrated about if an exception occurs (i.e. die is called). It is completely normal, it is "just" another way of control flow.

The butt-ugly alternative "solution" is to return some kind of error information in-band and check each and every function call result for error information. In other words, C:

/tmp>cat error.c
#include <stdio.h>
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>

int main(int argc, char ** argv)
{
        int fd;
        char buf[100];
        ssize_t n;

        fd = open("foo", O_RDONLY);
        if (fd == -1) {
                perror("failed to open foo"); /* evaluates errno */
                return 1;
        }

        n = read(fd, buf, sizeof(buf));
        if (n == -1) {
                perror("failed to read from foo");
                return 2;
        }
        if (n != sizeof(buf)) {
                fprintf(stderr, "Short read from foo (got %z, expected
+ %z)\n", n, sizeof(buf));
                return 3;
        }

        if (close(fd) == -1) {
                perror("failed to close foo");
                return 4;
        }

        // and so on ...
}

/tmp>make error
cc     error.c   -o error

/tmp>./error
failed to open foo: No such file or directory

/tmp>
[download]

Update: Yes, you could implement a kind of exception handling in C using setjmp/sigsetjmp and longjmp/siglongjmp. Be prepared for "interesting" results due to undefined behaviour ...

The smart way is to accept that things can go wrong:

try {
    line = console.readLine();

    if (line.length() == 0) {
        throw new EmptyLineException("The line read from console was e
+mpty!");
    }

    console.printLine("Hello %s!" % line);
}
catch (EmptyLineException e) {
    console.printLine("Hello!");
}
catch (Exception e) {
    console.printLine("Error: " + e.message());
}
else {
    console.printLine("The program ran successfully.");
}
finally {
    console.printLine("The program is now terminating.");
}
[download]

(Pseudocode-example stolen from Exception handling.)

This can be very useful e.g. if you need to work with a database:

Transactions

Transactions are a fundamental part of any robust database system. They protect against errors and database corruption by ensuring that sets of related changes to the database take place in atomic (indivisible, all-or-nothing) units.

[...]

The recommended way to implement robust transactions in Perl applications is to enable "RaiseError" and catch the error that's 'thrown' as an exception. For example, using Try::Tiny:

use Try::Tiny;
$dbh->{AutoCommit} = 0;  # enable transactions, if possible
$dbh->{RaiseError} = 1;
try {
    foo(...)        # do lots of work here
    bar(...)        # including inserts
    baz(...)        # and updates
    $dbh->commit;   # commit the changes if we get this far
} catch {
    warn "Transaction aborted because $_"; # Try::Tiny copies $@ into 
+$_
    # now rollback to undo the incomplete changes
    # but do it in an eval{} as it may also fail
    eval { $dbh->rollback };
    # add other application on-error-clean-up code here
};
[download]

If the RaiseError attribute is not set, then DBI calls would need to be manually checked for errors, typically like this:

$h->method(@args) or die $h->errstr;
[download]

With RaiseError set, the DBI will automatically die if any DBI method call on that handle (or a child handle) fails, so you don't have to test the return value of each method call. [...]

A major advantage of the eval approach is that the transaction will be properly rolled back if any code (not just DBI calls) in the inner application dies for any reason. The major advantage of using the $h->{RaiseError} attribute is that all DBI calls will be checked automatically. Both techniques are strongly recommended.

(Ripped right out of the DBI documentation.)

Update: Compare with "Exceptions" in Image::Magick: You have to check each and every return value, and you need to do that in at least three different ways, depending on what the function is expected to return. There is NO exception handing in Image::Magick.

The main point is that if you accidentally forget to check for errors, your programm will die. It won't chew on garbage that happens to linger around somewhere in memory and it won't produce any more garbage. It will just stop and exit with an error message. In C, omitting error checks will cause a lot of "interesting" results instead.

Alexander

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

However, I will not call die.

I agree with afoken's "WTF" here.

There are many instances where it would be dangerous to NOT throw an exception. For example... my webapp that front-ends a connection to Tesla's API... you hammer that too hard without a proper auth token and I don't throw, that may cause issues. I'm not going to nicely keep telling you to please don't do that, I'm breaking your caller.

Another example is my IPC::Shareable software. If you try to write to a memory location that isn't yours, you should know better, and I'm throwing an exception.

The case that's relative here is the test software. Your tests should use a liberal amount of throws_ok() or similar to ensure that you catch as many possible exception cases as your software throws.

Here's an example use of throws_ok():

use Test::Exception;


throws_ok
    { 0/0 }
    qr/Illegal division by zero/,
    "whatever_sub() throws if trying to divide by zero ok";
[download]

You can do it without Test::Exception with a bit more work:

my $div_by_zero_ok = eval {
    0 / 0;
    1;
};

is
    $div_by_zero_ok,
    undef,
    "whatever_sub() barfs properly if dividing by zero ok";
[download]