in reply to Re: Catching error in DateTime::Format
in thread Catching error in DateTime::Format

OP here—It's using Test::More.

Should I even be relying on eval at all? Or should I instead be checking it first, before I send it to DateTime::Format::ISO8601? Handling dates seems extremely complicated, and I don't know what the correct approach is. I'm also not sure where this error will go when running the actual code; if it's just an artifact of testing, I guess I can just comment out the test and not worry about it, if this output is going to vanish into thin air in real use.

  • Comment on Re^2: Catching error in DateTime::Format

Replies are listed 'Best First'.
Re^3: Catching error in DateTime::Format
by Corion (Patriarch) on Oct 27, 2025 at 19:14 UTC

    I think the approach is sound.

    The following script does not output the additional warnings, so it must be some other module that loads (say) Carp or something else that outputs these (caught) warnings.

    use 5.020; use Test::More; use DateTime; package MyApp::Util { # in MyApp::Util sub convert_datetime { my ( $self, $incoming_datetime ) = @_; my $new_dt; eval { $new_dt = DateTime::Format::ISO8601->parse_datetime( $i +ncoming_datetime ); }; return undef if $@; # No error, now we can convert the date (not shown) return $new_dt; } } my $bogus_datetime = MyApp::Util->convert_datetime("FOO"); is ($bogus_datetime, undef, "convert_datetime doesn't blow up if sent +bogus date"); done_testing;