email.errors：异常和缺陷类

源代码： Lib / email / errors.py

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

exception email.errors.MessageError

这是email包可以进行的所有异常的基类。它源于标准的Exception类，并定义了无附加方法.

exception email.errors.MessageParseError

这是Parser类引发的异常的基类。它来自MessageError。该类也由headerregistry.

exception email.errors.HeaderParseError

在解析RFC 5322 amessage的标题，这个类派生自MessageParseError。该set_boundary()如果在调用方法时内容类型未知，则会引发此错误.Header可能会针对某些base64decoding错误引发此错误，并且当尝试创建一个看起来包含嵌入标头的标头时（也就是说，应该是没有前导空格且看起来像标题的连续行）。

exception email.errors.BoundaryError

已弃用且不再使用.

exception email.errors.MultipartConversionError

当使用Message将有效载荷添加到add_payload()对象时，但是有效载荷已经是标量和主题Content-Type main类型不是multipart或者失踪。MultipartConversionError从MessageError和内置TypeError.

乘以@////由于Message.add_payload()已被弃用，这种异常在实践中很少被提及。但是如果attach()在MIMENonMultipart（例如。MIMEImage）.

这是FeedParser可以在解析消息时找到。请注意，缺陷会添加到发现问题的消息中，例如，如果消息嵌套在multipart/alternative有一个格式错误的标题，嵌套的messageobject会有一个缺陷，但包含的消息不会.

所有缺陷类都来自email.errors.MessageDefect.

  • NoBoundaryInMultipartDefect– 声称是多部分的消息，但没有boundary参数

  • StartBoundaryNotFoundDefect – Content-Type标题中声称的起始边界从未被发现.

  • CloseBoundaryNotFoundDefect– 找到了一个起始边界，但没有找到相应的近边界.

    3.3版本中的新文件.

  • FirstHeaderLineIsContinuationDefect – 该消息的续行为第一个标题行.

  • MisplacedEnvelopeHeaderDefect– 在一个标题块的中间找到了一个“Unix From”标题.

  • MissingHeaderBodySeparatorDefect – 在没有前导空格但没有包含’：’的解析头时发现了一条线。假设线条代表身体的第一条线，继续解析.

    3.3版本中的新文件.

  • MalformedHeaderDefect – 发现一个标题丢失了结肠，或者其他方面都是畸形的

    //从版本3.3开始不推荐使用：这个缺陷还没有用于几个Python版本.

  • MultipartInvariantViolationDefect – 一条消息声称是multipart，但没有找到任何子部分。请注意，当消息出现此缺陷时，即使其内容类型声称为is_multipart()，其multipart.

  • InvalidBase64PaddingDefect方法也可能返回false – 当解码base64encoded字节块时，填充不正确。添加足够的填充以执行解码，但生成的解码字节可能无效.

  • InvalidBase64CharactersDefect– 当解码base64encoded字节块时，遇到base64字母表之外的字符。字符被忽略，但得到的解码字节可能无效.

  • InvalidBase64LengthDefect – 解码base64编码字节块时，非数字-padding base64个字符无效（1个多于4的倍数）。编码的块被保存为–