Re: git-svn: copes poorly with .git/svn dir from older perl
Hi Jonathan,
On 05/09/2011 05:55 AM, Jonathan Nieder wrote:
I do not want to set $Storable::interwork_56_64bit, but just to trap and
silence errors like this and generate a new cache. Is there some variant
on
eval {
tie ...;
memoize ...;
}
if ($@) {
die unless $@ =~ /is not compatible/;
print STDERR "$@: discarding cache\n";
rmtree([$cache_path]);
mkpath([$cache_path]);
... try again ...
}
that would work well?
Mostly, yes. You do throw localization of error messages out of the
window, but we don't really have that in Perl anyway. Moreover,
exceptions in Perl still suck: Here's the somewhat best-practice for a
robust try/catch when not using extra modules:
if (not eval {
do_faily_stuff();
1;
}) {
my $err = $@ || "Zombie error";
die $err unless $err =~ /is not compatible/;
... recover ...
}
The unconditionally-true-return-value-except for exceptions pattern in
the if is more resilient than checking $@. This is because if there are
objects & destructors involved, you can have code clobbering the
original $@ if the destructors are buggy (need local $@!). Since this
kind of error leads to severe hair loss during debugging, there is the
"Zombie error" case that will fire in those nightmares. Then at least,
you know what you're looking at.
Alternatively, is there some other simple serialization format (YAML?)
in core perl that might allow keeping the cache with less fuss? (An
answer like "don't ask me; ask on perl monks" would be fine, too. The
most interesting thread I could find in a quick search was [2].)
I think Perlmonks would probably have been more appropriate. Perl 5.14
(tentative release date tomorrow, Wednesday) will contain a pure-Perl
JSON serializer/deserializer, but it is much slower than Storable.
Make sure to use Storable's nfreeze instead of freeze for the best
compatibility you can get.
Best regards,
Steffen
Reply to: