Skip Menu |
 

This queue is for tickets about the Net-IMAP-Simple CPAN distribution.

Report information
The Basics
Id: 129324
Status: rejected
Priority: 0/
Queue: Net-IMAP-Simple

People
Owner: Nobody in particular
Requestors: tlhackque [...] yahoo.com
Cc:
AdminCc:

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



Subject: Can't clear error state
Date: Fri, 26 Apr 2019 10:40:24 -0400
To: bug-Net-IMAP-Simple [...] rt.cpan.org
From: tlhackque <tlhackque [...] yahoo.com>
Once an error happens, errstr() will return it forever; there is no documented method for clearing the error state short of closing the mailbox and re-connecting with a new object. This is inconvenient, to say the least. Either or both of the following should happen: a) At the start of every operation, set $this->{_errstr} = ''; b) Provide a method along the lines of: sub clearerr {     my( $self ) = @_;     $self->{_errstr} = '';     return; } There are arguments for both: a) makes errstr() report on (only) the current operation b) will return the last error in a series of operations, until the application confirms that it saw it. An alternative is for errstr to clear {_errstr} after returning the error, which is simpler for everyone concerned, but would be a break with existing behavior...  It's not clear why anyone would call errstr twice for the same event (perhaps logging to a file and STDERR?), but users do the strangest things... sub errstr {     my $err = $_[0]->{_errstr};    $_[0]->{_errstr} = '';    return $err; }
Download (untitled) / with headers
text/plain 392b
Checking the _errstr is not the correct method of checking for an error. There's no need to clear it. You should be checking returns on the methods that can detect and report an error, eg: if( !$imap->login('blah','password') ) { die $imap->errstr; } -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.
Subject: Re: [rt.cpan.org #129324] Can't clear error state
Date: Thu, 9 May 2019 14:52:44 -0400
To: bug-Net-IMAP-Simple [...] rt.cpan.org
From: tlhackque <tlhackque [...] yahoo.com>
On 09-May-19 13:04, Paul Miller via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=129324 > > > Checking the _errstr is not the correct method of checking for an error. There's no need to clear it. > > You should be checking returns on the methods that can detect and report an error, eg: > > if( !$imap->login('blah','password') ) { > die $imap->errstr; > } > > >
Yes, of course I do that.  It's not always sufficient. Consider a search that returns 0 messages.  This can be because no match - which neither sets nor clears the error string.  Or because the server returned an error.  I need to do different things for the two cases.  In one case, blame the system.  In the other, blame the user. Let's say that login failed due to wrong password, leaving errstr set.   We retry with the correct password, succeed, and do a search that returns 0 messages. I use something like: my @msgs = $mbx->search( ... ); unless( @msgs ) {     my $err = $mbx->errstr;     report( $err? "Server error: $err\n": "No messages match\n"); } foreach (@msgs) ... How do you suggest that I tell the difference, if not errstr? For flag operations, you have the "waserr" mechanism.  It is not set by search, but that would be an alternative. There are other cases that leave an error string. mailboxes_subscribed() can return an empty list; the doc says "nothing is returned and errstr is set".  How do I distinguish "no mailboxes are subscribed" from a server failure? In theory, though less likely, so can mailboxes(). One odd case, arguably another bug, is executing starttls on a connection already running SSSL.  The starttls succeeds, but leaves an error message behind.  It's documented to die() on failure, but it doesn't in this case. This happens to be the case that triggered the bug report. My solution for all of the above was to subclass Net::IMAP::Simple with this errstr: sub errstr {     my $self = shift;     my $err  = $self->SUPER::errstr;     $self->{_errstr} = '';     return $err; } It's not the most elegant, but it is the smallest change to the existing code.
Download (untitled) / with headers
text/plain 701b
On Thu May 09 14:53:01 2019, tlhackque wrote: Show quoted text
> I use something like: > my @msgs = $mbx->search( ... ); > unless( @msgs ) { >     my $err = $mbx->errstr; >     report( $err? "Server error: $err\n": "No messages match\n"); > }
This is invalid with or without a reset. search() never attempts to set or clear the errstr. Search either returns results, or it doesn't. It has no error checking. Arguably, it should, but it doesn't. This form would be sortof valid for fetch, but it would be more like this: $res = $mbox-fetch(...); print $mbx-errstr if not $res; -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.