[Maypole] 2.07 PR

Dave Howorth dhoworth@mrc-lmb.cam.ac.uk
Tue, 18 Jan 2005 15:10:29 +0000


Tony Bowden wrote:
> On Tue, Jan 18, 2005 at 12:56:22PM +0000, Dave Howorth wrote:
>>so we are talking about different code that behave very differently
>>in the area we are discussing. 
> 
> I don't believe they do behave very differently here.

I'm confused by this. In the previous version (1.00)

   sub extract {
     my $self = shift;
     ...
     unless ($skip_valid) {
       if (my $ref = $handler->can('is_valid')) {
         unless ($handler->$ref()) {
           $self->{_ERR} =
            "$field ($self->{value}) does not pass the is_valid() check";
           return;
         }
       }
     }
     ...
   }

No eval. In fact there's only one eval in the whole module and even then 
there's a specific die after that to make sure it does die eventually. 
So any exception causes it to die. There've been conversations about it 
on this list before with no alternative views. That's why Maypole was 
changed to eval it, I believe.

In the new version (1.25)

   sub extract {
         my $self = shift;
         $self->{_ERR} = "";
         my $val = eval { $self->_do_extract(@_) };
         if ($@) {
                 chomp($self->{_ERR} = $@);
                 return;
         }
         return $val;
   }

   sub _do_extract {
	... much as before ...
   }

There's a whole new subroutine specifically to wrap everything in an 
eval and make sure it never dies.

I really don't see how to interpret this as not different?

> With regards to any of this there was really no new documentation
> required.

We'll just have to agree to differ there.

BTW, the docs were nonetheless changed a bit and I just spotted a typo; 
the docs say "datetime - a date (into a DateTime)" but the datetime 
handler actually creates Time::Piece objects, which is why I have 
written my own handler to create DateTime ones. It's a very misleading name.

Cheers, Dave