The big question is: Can your program run despite the file open failing? If, for example, you're writing something that digests a log file, and you fail opening the log file, give up the ghost. There's no point in trying to continue. OTOH, if your program can limp along without the file, then just issue a warning and continue. (Continuing the same "digest-a-log-file" example, say you can't open the password file to map UIDs to login names; you can process the log file, although you probably want to tell someone you couldn't open the file. (Contrived example, you get the idea.))

The next question is, what does "issue a warning" mean? That depends very much on the programming shop in which you're running, and whom you want to alert. Don't think in terms of "most elegant", think in terms of "most useful". The appropriate thing may be to write a record in a log file, send an email, or even use CGI::Carp qw(fatalsToBrowser).

Your question also involved using if/else to handle file open errors. This really goes to some programming style issues. I personally despise style guidelines that assert that an if should always "exit at the bottom". To me, code structured like this is a nightmare:

if (open(FH, $file))
{
    ...complicated logic extending many many lines....
    close(FH);
}
else
{
    warn "Couldn't open $file: $!"\n";
}
[download]

because after comprehending the complicated logic in the first block, I have to pop my mental stack and say, "Now who the heck does this else belong to?"

To me, the else block is part of the file opening logic and should be kept together. That is, the code should do something more like this:

unless (open(FH, $file))
{
    ...send email, sound the klaxons, raise a ruckus, etc.
    ...if I really can't continue, I'll die or exit here.
}
else
{
    ....do fun stuff with FH
}
[download]

The key point about style, IMHO, is to keep all the file open handling logic together.

HTH