[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

	eval {
		tie ...;
		memoize ...;
	if ($@) {
		die unless $@ =~ /is not compatible/;
		print STDERR "$@: discarding cache\n";
		... 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 {
}) {
  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,

Reply to: