Re: stronger than eval?

use statements are evaluated at compile time, so a block eval won't catch it. You can use a string eval if you need to force the use statement to happen at runtime.

BEGIN { 
    eval "use Cache::File";
    if($@) {
        # Do remedial action
    }
}
[download]

Comment on Re: stronger than eval? Download Code

Replies are listed 'Best First'.
Re^2: stronger than eval? by andyford (Curate) on Sep 21, 2006 at 19:03 UTC
This works great except STDERR gets printed to the console and $@ just gets STDOUT. Any way to fix that? Just so the user gets clean output... andyford or non-Perl: Andy Ford	[reply]
Re^3: stronger than eval? by ysth (Canon) on Sep 21, 2006 at 19:51 UTC
That's not quite right; $@ will get the exception (aka "die" message). Anything directly written out to STDERR or STDOUT will not be caught, unless you tie those filehandles (only works for output by perl) or reopen them. If the output is due to a warn, you can catch it with a $SIG{__WARN__} handler.	[reply]
Re^4: stronger than eval? by andyford (Curate) on Sep 21, 2006 at 20:38 UTC
Oh OK right I see. Part of my error is the shell, and part is perl. Lifted this from the open docs. `open OLDERR,">&",\*STDERR or die "Can't dup STDERR: $!"; open STDERR,'>>',"foo.out" or die "Can't redirect STDERR: $!"; eval 'use Cache::File'; open STDERR, ">&OLDERR" or die "Can't dup OLDERR: $!";` [download] but I get a `Name "main::OLDERR" used only once: possible typo...` [download] Is there another way to express the last open, or do I have to do the local "no warnings" thing that I read about a couple times many years ago? andyford or non-Perl: Andy Ford	[reply] [d/l] [select]
Re^5: stronger than eval? by cephas (Pilgrim) on Sep 22, 2006 at 00:18 UTC