[Bioperl-l] Not catching an error in EUtilities

[Chris Fields]

Warren,

For efetch the following works for me; it include a simple callback  
to check the initial data chunk (note the die in the callback and the  
extra call to check the header) and prints to the file if no error is  
detected, otherwise it retries.  I'll see if there is an easy way to  
integrate this into EUtilities.


# after eutil calls

open (my $SEQFILE, '>', $file) || die "Can't write to file:$!";
my $expected;
my $bytes = 0;

RETRIEVE_SEQS:
while ($retstart < $count) {
      $gpeptfactory->set_parameters(
		-retmax => $retmax,
                 -retstart => $retstart,
                              );
      my $response;
      eval{
         $response= $gpeptfactory->get_Response(-cb => sub {
            my ($chunk, $res) = @_;
             if ($bytes == 0 && $chunk =~ m{^Error:(.*)}i) {
                 die "$1\n";
             }
             $bytes += length($chunk);
             print $SEQFILE $chunk;
         });
      };
      if ($@ || $response->header('x-died')) {
          my $error = $@ || $response->header('x-died');
          die "Server error: $error.  Try again later" if $retry == 5;
          print STDERR "$error\n";
          print STDERR "Server error, redo #$retry\n";
          $retry++ && redo RETRIEVE_SEQS;
      } else  {
      	my $retend = $retstart + $retmax;
      	print "Loaded entries ",$retstart+1," through $retend on retry  
# $retry.\n";
      	$retstart += $retmax;
      	$retry = 0;
         $bytes = 0; # important!
         undef $expected ;
      }
}

close $SEQFILE;

chris

On Oct 28, 2007, at 11:03 PM, Warren Gallin wrote:

> I've been having an intermittent problem, when the NCBI service that
> is accessed by EUtilities (in particular efetch) is not available.
>
> I have the calls enclosed in eval statements, but an exception is not
> thrown.  Instead I find that the  file that should contain the
> results of the efetch only has the following text:
> ...
> If so, is there a standard way of checking for this?
>
> Thanks,
>
> Warren Gallin
...