eval {
    open(FH, $file)         or die "NO_OPEN";
    $text = join('', <FH>)  or die "NO_READ";
    close(FH)               or die "NO_CLOSE";
}
if ($@) { ... }
[download]

open(FH, $file)            or &error("NO_OPEN",  $file, $!);
my $text = join('', <FH>)  or &error("NO_READ",  $file, $!);
close(FH)                  or &error("NO_CLOSE", $file, $!);
[download]

You can (as in "have the potential to be able to") recover in the eval block. Can you recover in your error sub? I find the block more flexible that way, if that's the sort of thing that's necessary.

(Feel free to drop the leading ampersand. It doesn't add anything in this case, and is often better removed.)

In your example, the second option is actually more readable. But if the function call on the left is longer, and you start wrapping things will get pretty ugly. What's more, if you do something like $sth->execute and the transaction fails (e.g. from bad SQL or an RI constraint) $sth->execute will call die() for you - and an eval block is the only way to catch it.

I prefer to use the same method for something every time - so I go for nothing but eval blocks. Using two different constructs to do the same thing in the same bit of software just makes things harder to maintain. YMMV.