Given a block (BLOCK), the block will be compiled at compile-time, rather than run-time (as in the EXPR form). If an error occurs in the expression/block that you're executing, the error message will be in the $@ variable after your eval.

In other words, eval, in combination with die, can be used as an exception mechanism in Perl. For example, you can try to require a module in an eval block, then check $@ (the "exception", in this case) to see if the require has succeeded:

eval {
    require LWP;
};
if ($@) {
    die "Can't load LWP: $@";
}
[download]

If I understand you correctly, this may solve a problem I've been dealing with when I have scripts designed to work on NT and UNIX.
Would this work?


$is_NT = ($ENV{'OS'} eq 'Windows_NT');
if ($is_NT) {
  eval { use Win32::ODBC; }
} else {
  eval { use DBI; }
}
[download]

The problem exists because Win32 doesn't happen to be on my UNIX box. :) Is there another way to conditionally use a module?

That snippet doesn't do anything if the use() fails. And, what if it is NT but Win32::ODBC isn't installed? What if it is a Win32 system with DBI installed? How about:

eval { require DBI };
if ($@) {
   warn "DBI not here.. will keep checking...";
}
eval { require Win32::ODBC };
if ($@) {
    warn "Oh oh";
}
... etc...
[download]

or (ok, this is far fetched):

my %subs = ('DBI' => \&use_dbi,
            'Win32::ODBC' => \&use_odbc,
            'Win32::OLE' => \&use_ole
            );
my @mods = ('DBI', 'Win32::ODBC', 'Win32::OLE');
for (@mods) {
    eval { require $_ };
    if ($@) {
       warn "No $_ here";
    }else{
       $subs{$_}->();
       last;
    }
}
[download]

Cheers,
KM

Shendal, this is totally off the eval topic, but why not just stick with one flavor? I've used DBI on Win32 and UNIX, with great results (even porting from one to the other was great). Is there any specific reason why you would want to use Win32::ODBC instead of DBI? You'll have to change the connect string that creates the database handler anyway.

Just my R$0.02.

#!/home/bbq/bin/perl
# Trust no1!

Out of curiosity, why would you eval the require, then die if the eval fails? If the require fails it would die anyways. Something like this makes a little more sense (to me):

my $bad;
BEGIN {
   eval { require Foo };
   if ($@) {
    $bad = "Foo";
    warn "This requires $bad to work. " .
             "You can get it at ... ";
   }
}

sub new {
    return undef if $bad;
    ...etc...
}
[download]

Cheers,
KM

Well... would you believe that it wasn't a very good example? :)

That said, there are several situations where I might do something like this:

• When my eval to require the module is wrapped in another eval, where the outer eval is a general exception handler of sorts. In this case, I'd perhaps have an exception handler set up for this particular exception: loading a module failed. So I'd die w/ that particular exception object (using 5.005's (I think) ability to die with an object). I do this often in mod_perl apps... in fact, I probably abuse the technique. :)

• This is kind of similar to the first example, but oftentimes I'd rather give an explanation of why the module-load failed, rather than just give the standard "can't find in @INC" message. As you did above, in fact.
What I do wonder is why you're using warn above. If code you're writing absolutely requires a module to work, why wouldn't you want to die? Just wondering.

eval "$val= ; ";
if ( $@ eq "")
{ print "this is valid"; }
else 
{ print "$@ is invalid"; }
[download]

• Checking for die conditions without die-ing
• Giving great user flexibility to specify options in config files. For example, I'm working with a program that has data files that are in essence miniature programs. The datafiles are loaded during run, and each mini-program will need to be executed many times. My solution? I translate the programs into perl when the file is loaded, and eval() them when I need to.