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 unparseableblock - 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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Email-SIG mailing list [email protected] Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
