>>>>> "RM" == Rick Measham <[EMAIL PROTECTED]> writes:
>> DateTime-TimeZone-0.2503/Build.PL + 'DateTime' => 0,
RM> If you do that, then you can't install it :) DateTime requires
RM> that DateTime::TimeZone be installed before it will
RM> install. So if you make DateTime::TimeZone require that
RM> DateTime be installed, then neither can install.
Ouch! Ok, this could be fixed by more documentation and clearer
diagnostics.
>> DateTime-TimeZone-0.2503/lib/DateTime/TimeZone.pm + die
>> "Invalid time zone name: $p{name}\n$@" if $@;
RM> This is a good suggestion, but returning $@ doesn't happen in
RM> many (any?) (IIRC) other places in DateTime. Personally I'd
RM> like to get back confess() rather than die .. then you know
RM> where it went wrong.
Here $@ is set by eval. There should not be more "other places".
Replacing `die' with `confess' is orthogonal here. I guess most times
the problem will be in missing DateTime.pm module. So that should be
diagnosed clearly.
You can check for more exact contents of $@:
my $module_name = "Foo::Bar::Baz";
eval "require $module_name;";
if ($@){
# Foo::Bar::Baz ==> Foo/Bar/Baz.pm
(my $module_filename = $module_name) =~ s,::,/,g;
$module_filename .= ".pm";
if ($@ =~ /^Can't locate \Q$module_filename\E/)) {
# the constructed module itself not found
die "Timezone '$timezone_name' not found or invalid";
} else {
# missing DateTime.pm, or typo in module, or something else
die; # propagating $@
}
}
I use dynamically-constructed module names a lot, and always use this
technology.
RM> DateTime-TimeZone-0.2503/lib/DateTime/TimeZone.pm SYNOPSIS
>> + use DateTime; + my $datetime = DateTime->now(); + my $offset
>> = $tz->offset_for_datetime($datetime);
RM> Rather than this, maybe we need to add a note to all modules
RM> to signify that $datetime and $dt refer to DateTime.pm
RM> objects.
That's ok, but _something_ should be said about $datetime. I passed
time() at first, and was surprised to see the diagnostics.
Thanks,
--alexm
