The sentiments on this reply say "die" which is normally what I'd like to do, but in this particular case, a failure isn't necessarily fatal.

I'm creating a Perl interface to a third party program, and in this case, I am reading an attribute. If the attribute exists, I return its value, if not, I return nothing. However, I might be returning nothing because the value isn't set, or I might be returning nothing if the user's login credentials expired, or I might be returning nothing because the server is down.

Dying because the return value is unavailible isn't set is not good. Maybe the user wants to set the attribute if it isn't already set. At the same time, if the server is down or I'm not logged in, I don't want to assume that the value isn't set and continue on my merry way.

Setting a package variable makes the most sense. However, I do see value in the throw/catch via eval idea. If something unexpected happens and the developer is asleep at the wheel, it is best to put the progam into full stop and not let the error grow until it does irreversible damage.

The problem is I hate the "throw/catch" syntax because it breaks the flow of the program -- especially Perl's way of using eval to do the catching.

An interesting possibility is to die -- unless the developer sets a package variable to allow a one time "don't die" call. If the developer wasn't paying attention, I die and stop the execution. If the developer sets the "don't die" flag, I can assume the developer is paying attention and wants to handle the error. In that case, I'll set the package variable.