Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misleading diagnostic during constructor eval #16

Open
autarch opened this issue Nov 12, 2016 · 2 comments
Open

Misleading diagnostic during constructor eval #16

autarch opened this issue Nov 12, 2016 · 2 comments
Labels

Comments

@autarch
Copy link
Member

autarch commented Nov 12, 2016

Migrated from rt.cpan.org #98588 (status was 'stalled')

Requestors:

From gmarler@bloomberg.net on 2014-09-03 15:02:22:

I noticed this when I missed one of the dependencies (List::AllUtils) that was added in v1.71, at which point all attempts to create a DateTime::TimeZone object failed with this message:

'Cannot determine local time zone'

Turns out this message is seriously misleading.

Tracing through the debugger, I came across this eval, which in v1.74 is located at line 74 of lib/DateTime/TimeZone.pm:

    my $e = do {
        local $@;
        local $SIG{__DIE__};
        eval "require $real_class";
        $@;
    };

If the class being require'ed isn't available, you should get the actual message returned, like so:

Can't locate List::AllUtils in @inc ...

But you don't. Fixing this would probably eliminate a lot of confusing bug reports against this module.

@autarch
Copy link
Member Author

autarch commented Nov 12, 2016

From drolsky@cpan.org (@autarch) on 2014-09-13 19:56:07:

On Wed Sep 03 11:02:22 2014, gmarler@bloomberg.net wrote:

I noticed this when I missed one of the dependencies (List::AllUtils)
that was added in v1.71, at which point all attempts to create a
DateTime::TimeZone object failed with this message:

'Cannot determine local time zone'

Turns out this message is seriously misleading.

Tracing through the debugger, I came across this eval, which in v1.74
is located at line 74 of lib/DateTime/TimeZone.pm:

my $e = do {
local $@;
local $SIG{DIE};
eval "require $real_class";
$@;
};

If the class being require'ed isn't available, you should get the
actual message returned, like so:

Can't locate List::AllUtils in @inc ...

But you don't. Fixing this would probably eliminate a lot of
confusing bug reports against this module.

That's the message I get. I'm using Perl 5.10.1 & 5.16.3, so either this is a problem with your version of Perl or something else is going on.

Can you come up with a test to replicate this bug?

@autarch
Copy link
Member Author

autarch commented Nov 12, 2016

From gmarler@bloomberg.net on 2014-09-13 20:58:42:

I got it with 5.18.1. not quite sure how I would test for that, but I'll give it some thought.


Sent from Bloomberg Professional for Android

----- Original Message -----
From: Dave Rolsky via RT bug-DateTime-TimeZone@rt.cpan.org
At: Saturday, September 13, 2014 15:56

<URL: https://rt.cpan.org/Ticket/Display.html?id=98588 >

On Wed Sep 03 11:02:22 2014, gmarler@bloomberg.net wrote:

I noticed this when I missed one of the dependencies (List::AllUtils)
that was added in v1.71, at which point all attempts to create a
DateTime::TimeZone object failed with this message:

'Cannot determine local time zone'

Turns out this message is seriously misleading.

Tracing through the debugger, I came across this eval, which in v1.74
is located at line 74 of lib/DateTime/TimeZone.pm:

my $e = do {
local $@;
local $SIG{DIE};
eval "require $real_class";
$@;
};

If the class being require'ed isn't available, you should get the
actual message returned, like so:

Can't locate List::AllUtils in @inc ...

But you don't. Fixing this would probably eliminate a lot of
confusing bug reports against this module.

That's the message I get. I'm using Perl 5.10.1 & 5.16.3, so either this is a problem with your version of Perl or something else is going on.

Can you come up with a test to replicate this bug?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

1 participant