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