Re: fixing the current email module

On Wed, Oct 07, 2009 at 10:51:03PM -0400, Barry Warsaw wrote:
> On Oct 7, 2009, at 1:07 PM, Oleg Broytman wrote:
>
>> On Wed, Oct 07, 2009 at 11:23:24AM -0500, Matthew Dixon Cowles wrote:
>>> In my opinion, the email module should never raise an exception as a
>>> result of working with a malformed message. Though it should
>>> certainly make the information that a message was malformed available
>>> for the calling program to check.
>>
>>   I disagree. email package is not a user agent, and exceptions are  
>> *the*
>> way to indicate there are problems.
>
> By keeping the various components clear in our mind, we can see that  
> both statements are correct in a sense.  The parser and generator should 
> never raise exceptions.  The model can and probably should.

   Are you going to parse any garbage and create a Message (probably an
empty Message) with one defect "cannot parse it at all"?

>> But if a parser stumbles upon an  
>> unparseable
>> block - it must raises an exception.
>
> No.  It really can't.   Let's say your MTA dropped a bunch of bytes in a 
> file and in some low-level background process you read those bytes and 
> turn them into Message trees.  Now your parser throws an exception: what 
> can you possibly do about it except throw away this unparseable jumble of 
> bytes and log the exception?

   I don't disagree with that. If a parser can parse an input in some way -
let's consider the input a malformed message and create a Message with
defects.
   What I disagree with is that if a parser cannot parse input garbage at
all it must raise an exception. And if a parser can raise an exception any
calling program must be prepared to catch such exceptions.

Oleg.
-- 
     Oleg Broytman            http://phd.pp.ru/            [email protected]
           Programmers don't die, they just GOSUB without RETURN.