[Email-SIG] fixing the current email module
barry at python.org
Thu Oct 8 04:51:03 CEST 2009
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
> 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
> more intelligent parser(s). But if a parser stumbles upon an
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: This is a digitally signed message part
More information about the Email-SIG