18.1.8. email.errors：异常和缺陷类

email.errors模块中定义了以下异常类：

• exception email.errors. MessageError

  • 这是email程序包可能引发的所有异常的 Base Class。它是从标准Exception类派生的，并且没有定义其他方法。

• exception email.errors. MessageParseError

  • 这是Parser类引发的异常的 Base Class。它是从MessageError派生的。

• exception email.errors. HeaderParseError

  • 在解析消息的 RFC 2822Headers 时在某些错误条件下引发，此类从MessageParseError派生。可以从Parser.parse或Parser.parsestr方法中提出。

可以提高它的情况包括：在邮件的第一个 RFC 2822头之后找到一个信封头，在找到第一个 RFC 2822头之前找到一个连续行，或者在头中找到既不是 Headers 也不是连续行的行。

• exception email.errors. BoundaryError
  • 在解析消息的 RFC 2822Headers 时在某些错误条件下引发，此类从MessageParseError派生。可以从Parser.parse或Parser.parsestr方法中提出。

可以提高它的情况包括：使用严格解析时，无法在* multipart/**消息中找到起始或终止边界。

• 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的子类，但是此类也不 exception！

2.4 版的新Function：添加了所有缺陷类。

• NoBoundaryInMultipartDefect –声称是 Multipart 消息，但没有* boundary *参数。

• StartBoundaryNotFoundDefect –从未找到* Content-Type *Headers 中语句的起始边界。

• FirstHeaderLineIsContinuationDefect –邮件的第一行标题为连续行。

• MisplacedEnvelopeHeaderDefect-在 Headers 块的中间发现“ Unix From”Headers。

• MalformedHeaderDefect –发现 Headers 缺少冒号或格式不正确。

• MultipartInvariantViolationDefect –声称是* multipart 的消息，但未找到任何子部分。请注意，当消息存在此缺陷时，即使其 Content Type 声称为 multipart *，其is_multipart()方法也可能返回 false。