It's a TIMTOWTDI and philosophical issue as to how your API returns errors - just make sure your API is consistent once you choose an approach! The first two of your code examples are pretty common ways of handling it. On the other hand, the "user has to check an additional variable after calling my method" design is not to my personal taste, even though it's a classic (e.g. errno).

If the error condition is something that happens relatively often, do you really want to force a user to eval (or equivalent) all of your methods (personally I wouldn't), or is it really a fatal error which interrupts the program flow? Is the error something internal to the method that really shouldn't have gone wrong (like assertions; I might die in that case), is it an error from an underlying layer such as a database that your code is simply passing along, or is it something the user of the method did wrong?

Remember that there are other ways to return things from methods, such as returning multiple values, pass-by-reference parameters, setting fields on the object, etc.

In a language like Java, where exception handling is built-in, using exceptions is a bit more common. I'd say that exception handling is not "truly built in" to Perl because for a long time eval didn't have a fully reliable $@ error message (see for example "Background" in Try::Tiny). Instead, many Perl APIs chose to return false values on failures.

Note you may want to look into Carp instead of die, especially if the errors are something the caller of the method did wrong the error messages are more helpful.

Regarding your third example, because of the aforementioned issues with $@, the more reliable way to use eval is: my $success = eval { $result = whatever(); 1 };

(By the way, in your code examples, do you really mean to interpolate $object into the string?)