Re: fixing the current email module

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.

>   Yes, if email parse a message in some way - ok. You can help by  
> creating
> more intelligent parser(s). 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?

Much much better is soldier on and produce a Message object that has  
the right format, but additional information, such as a set of defects  
it encountered.  This is what the current email package does and it  
has made Mailman's life infinitely better (when it all DTRT).  If you  
have a Message with defects, you can reason about it, show partial  
information, attempt a repair, etc.  With an exception, you're hosed.

-Barry