email.errors：异常和缺陷类
源代码： Lib/email/errors.py
email.errors模块中定义了以下异常类：
-
exception
email.errors.MessageError -
exception
email.errors.MessageParseError- 这是Parser类引发的异常的 Base Class。它是从MessageError派生的。 headerregistry使用的解析器也在内部使用此类。
-
exception
email.errors.HeaderParseError- 在解析消息的 RFC 5322Headers 时在某些错误条件下引发，此类从MessageParseError派生。如果调用该方法时 Content Type 未知，则set_boundary()方法将引发此错误。 Header可能会因某些 base64 解码错误而引发此错误，并且在try创建似乎包含嵌入式 Headers 的 Headers 时(也就是说，应该有一个没有前导空格且看起来像 Headers)。
-
exception
email.errors.BoundaryError- 已弃用，不再使用。
-
exception
email.errors.MultipartConversionError- 使用
add_payload()将有效负载添加到Message对象时引发，但是有效负载已经是标量，并且消息的* Content-Type 主要类型不是 multipart *也不丢失。 MultipartConversionError继承自MessageError和内置的TypeError。
- 使用
由于Message.add_payload()已被弃用，因此在实践中很少会引发此异常。但是，如果在从MIMENonMultipart(例如MIMEImage)派生的类的实例上调用attach()方法，也会引发异常。
这是FeedParser在解析消息时可以发现的缺陷列表。请注意，缺陷会添加到发现问题的消息中，因此，例如，如果嵌套在* multipart/alternative *内部的消息具有错误的 Headers，则该嵌套的消息对象将具有缺陷，但包含的消息则不会。
所有缺陷类别都从email.errors.MessageDefect子类化。
-
NoBoundaryInMultipartDefect–声称是 Multipart 消息，但没有* boundary *参数。 -
StartBoundaryNotFoundDefect–从未找到* Content-Type *Headers 中语句的起始边界。 -
CloseBoundaryNotFoundDefect–找到了起始边界，但从未找到相应的闭合边界。
版本 3.3 中的新Function。
-
FirstHeaderLineIsContinuationDefect–邮件的第一行标题为连续行。 -
MisplacedEnvelopeHeaderDefect-在 Headers 块的中间发现“ Unix From”Headers。 -
MissingHeaderBodySeparatorDefect-在解析 Headers 时发现一行，该 Headers 没有前导空格，但不包含“：”。假设该行代表正文的第一行，则 continue 分析。
版本 3.3 中的新Function。
MalformedHeaderDefect–发现 Headers 缺少冒号或格式不正确。
从版本 3.3 开始不推荐使用：此缺陷尚未在多个 Python 版本中使用。
-
MultipartInvariantViolationDefect–声称是* multipart 的消息，但未找到任何子部分。请注意，当消息存在此缺陷时，即使其 Content Type 语句为 multipart *，其is_multipart()方法也可能返回False。 -
InvalidBase64PaddingDefect–解码 base64 编码字节块时，填充不正确。添加了足够的填充以执行解码，但是生成的解码字节可能无效。 -
InvalidBase64CharactersDefect–解码 base64 编码的字节块时，遇到了 base64 字母以外的字符。字符将被忽略，但finally的解码字节可能无效。 -
InvalidBase64LengthDefect–解码 base64 编码的字节块时，非填充的 base64 字符数无效(1 大于 4 的倍数)。编码的块保持原样。