Skip Menu |

This queue is for tickets about the Archive-Extract CPAN distribution.

Report information
The Basics
Id: 61385
Status: new
Priority: 0/
Queue: Archive-Extract

People
Owner: Nobody in particular
Requestors: david [...] kineticode.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Unknown Type Leads to No Error
Date: Wed, 15 Sep 2010 23:23:31 -0700
To: bug-archive-extract [...] rt.cpan.org
From: David E. Wheeler <david [...] kineticode.com>
new() has this: ### don't know what type of file it is ### XXX this *has* to be an object call, not a package call return $parsed->_error(loc("Cannot determine file type for '%1'", $parsed->{archive} )) unless $parsed->{type}; So if it's an unknown type, it passes the error to _error(). Fair enough. Except that _error() ends with: return; So it's stashed the error in the object, but since it returns nothing, new() therefore also returns nothing. Which means I have no object on which I can check error(). Which means I can't catch this exception. Looking at t/01_Archive-Extract.t, this looks to be intentional: my $ae = $Class->new( archive => $Me ); ok( !$ae, " No archive created based on '$Me'" ); ok( !$Class->error, " Error not captured in class method" ); ok( $warnings, " Error captured as warning" ); like( $warnings, qr/Cannot determine file type for/, " Error is: unknown file type" ); Since in my app I don't want it emitting warnings, I've turned them off. I guess I could catch this exception by setting $SIG{__WARN__} to something, but that's annoying. Couldn't new() return an object in this case? Or maybe die? I can handle either of those cases and it would be relatively reasonable. Thanks, David (Working on PGXN http://pgxn.org/)