Chris Dolan wrote:
Advice? While this example is contrived, the "eval { require ... }"
idiom is used often in the wild, so this is not a wholly unrealistic
scenario.
Real-world example. SVN::Web uses this idiom to determine whether to
use CGI or CGI::Fast.
Even if CGI::Fast is installed i
Chris Dolan writes:
> The problem is that I don't know how to distinguish between a load
> failure or a compile failure.
In this particular case you can get the failure by removing Bar from
%INC before checking that it loads:
use_ok('Foo');
delete $INC{'Bar.pm'};
use_ok('Bar');
In general
On 3/5/06, Chris Dolan <[EMAIL PROTECTED]> wrote:
> On Mar 5, 2006, at 3:55 PM, David Wheeler wrote:
>
> > On Mar 5, 2006, at 13:52, Chris Dolan wrote:
> >
> >> Advice? While this example is contrived, the "eval
> >> { require ... }" idiom is used often in the wild, so this is not a
> >> wholly un
On Mar 5, 2006, at 3:55 PM, David Wheeler wrote:
On Mar 5, 2006, at 13:52, Chris Dolan wrote:
Advice? While this example is contrived, the "eval
{ require ... }" idiom is used often in the wild, so this is not a
wholly unrealistic scenario.
Of course it should be
eval { require Bar; 1
On Mar 5, 2006, at 13:52, Chris Dolan wrote:
Advice? While this example is contrived, the "eval
{ require ... }" idiom is used often in the wild, so this is not a
wholly unrealistic scenario.
Of course it should be
eval { require Bar; 1; } or die $@;
But I agree that it seems like if t
I encountered a real-world case where Test::More's use_ok() passed
when the specified package had a fatal syntax error. I'm looking for
advice about whether I should file a bug, or fix my code that
triggered the false positive. Read on for details...
Consider two packages Foo.pm and Bar.p
