Oleg Broytman writes:
> 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.
Although practicality beats purity.
The email package has access to the wire format, and knows what to do
with most of it. It should DTRT where that is possible, and punt
where not. By "punt" I mean return a special object containing as
much of the meta data for an object as it could recover, along with
the data itself as a blob.
I would suggest that module utilities that require access to the
parsed form of data be designed as object methods. The special
objects produced when broken wire format is encountered wouldn't have
those methods, and thus they'd fail the duck type test. But that
makes sense: that "duck" can't quack anyway.
So this gives our (== Matt and me) desideratum that email never raises
(it's the Python runtime that will raise AttributeError), and also
Oleg's (in part, anyway): an exception *will* be raised.
I think (== hope) that this will sufficiently localize the issues that
even though only AttributeError would even be raised, it will be
obvious what went wrong.
> Then the calling program must catch all exceptions
That is just unreasonable. There are too many ways for things to go
wrong. If you have just one exception for all problems, it's easy to
catch them all, but then the client doesn't know what went wrong, and
has to partially parse the unparsable itself. That's nuts; the reason
for using the email module is to delegate that in the first place, and
besides, to the extent it's possible, the module has presumably done
that.
OTOH, a long list of precise exceptions is both a maintenance burden
on the email module and on client programmers.
> 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, that's the last thing you want it to do. Suppose you have
Content-Type: multipart/alternative
Content-Type: text/plain
Content-Type: text/html; body-parseable=no
Clearly you want (a) a vanilla email client to just grab the
text/plain part, and (b) a client written by somebody whose boss uses
BustedMUA[tm] to be able to try to parse the text/html part, using the
special rules that apply to the jumble produced by BustedMUA.
In other cases, you might be able to find a valid part terminator, but
the header of that part was hosed. So the whole part becomes a blob,
but the parser should resync at that point, and start parsing
following parts.
I can think of no input for which the parser should *ever* throw an
exception. Utilities that depend on a particular object's parsed form
might have do so, but even then it should be avoided if at all
possible.
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
