My basic theory is that there are two kinds of exceptions: those you can recover from (e.g. user input problem, or a situation where you have a backup approach to try) and those you can't (the database server exploded, some buggy code called a sub with the wrong args). I usually call the second type "system exceptions." There's really no point in catching this kind of exception at a low level, since there's nothing you can do to recover from it seamlessly. Your goal at this point is to get the error into the log, and send a pretty error page to the user.

The simplest approach to this is to just make a nice custom error page and tell your web server to use it. If you can't do that, you can put an eval at the very top level of your program so that it will catch any uncaught exceptions and have a chance to log them and send the pretty page. There is some advantage to doing it that way, in that you can do more extensive logging, including a stack trace in some situations.

I definitely think croak'ing is the correct behavior for H::T in the situation you mention. Returning error codes is a major source of bugs, because no one ever checks them consistently. Just look at DBI. People who use it without RaiseError turned on invariably have code where they fail to check return codes, resulting in failures further along in the code and highly confusing error messages. Throwing an exception is a much better way to handle an error that prevents the successful completion of a method call.