[Tickets #12265] Re: IMAP package throws errors
noreply at bugs.horde.org
noreply at bugs.horde.org
Thu May 23 17:14:05 UTC 2013
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: http://bugs.horde.org/ticket/12265
------------------------------------------------------------------------------
Ticket | 12265
Updated By | Michael Slusarz <slusarz at horde.org>
Summary | IMAP package throws errors
Queue | Horde Framework Packages
Version | Git master
Type | Bug
State | Unconfirmed
Priority | 1. Low
Milestone |
Patch |
Owners |
------------------------------------------------------------------------------
Michael Slusarz <slusarz at horde.org> (2013-05-23 11:14) wrote:
> But additionally I'm still convinced that a good function should
> filter out garbage input to prevent crashes or loops as this one.
You are confusing the scope of the function.
In a public API, in which I (as a developer) do not have control over
the input, then yes - it makes sense (when possible) to check for bad
input.
However, this is a private function. All input is controlled by the
developer. These functions SHOULD be very strict about data inputs
since, if an input is incorrect, that is a giant red flag that
something is probably wrong in the calling code.
The _readLine() function is only called from functions that MUST have
an active IMAP connection. If that is not happening, then this error
must be fixed at the source. Fixing it there will actually fix the
problem rather than suppressing the error messages.
> I'll need some days to dive into it, I'll call back once I know the
> reason forthe null resources.
Shouldn't be that difficult. You just need to post the backtrace part
of the debug output. SInce $_stream should never be null in that
method, any trigger of the debug code has found an issue. (I'm not
asking for a patch of the broken code - I'm just asking for help in
finding where the broken code is).
More information about the bugs
mailing list