The reasoning behind this is simple. Its easy to handle an exception, you can catch it, you can ignore it, you can re-throw it. All of this without cluttering the interface with random error variables and having to test returns at every single operation.

Exceptions didn't catch on for no reason, they are an elegant and effective method of error handling and indeed I find myself having a very hard time writing software in languages that don't support them.

Let us take the example of a database error for example. If the DBI module threw useful exceptions when things went wrong, I would no longer have to sit there checking the return on every little operation to make sure things went ok. I could wrap my entire atomic operation in an eval {}, catch any exceptions I found relevant and re-start the entire operation or provide *useful* input to the user if necessary. Easy, clean, effective.

Think twice before dissing die(), its a big strength. That said, no interface should die() without the documentation stating what exceptions are thrown and when :)