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/ p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
