On Thu, Oct 08, 2009 at 08:25:41PM +0900, Stephen J. Turnbull wrote:
> Oleg Broytman writes:
> > 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.
The special object is an instance of an exception class ;)
> 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.
Not exactly. One can see an AttributeError, but what was the cause? why
a parser has created a broken object? AttributeError doesn't preserve
information from parser.
> I can think of no input for which the parser should *ever* throw an
> exception.
Are you saying that even a random garbage would be parsed to a Message
of some kind? No headers, a single unparsed body?..
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
