email.errors: Exception and Defect classes

소스 코드: 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 헤더를 구문 분석할 때 일부 에러 조건에서 발생합니다. 이 클래스는 MessageParseError에서 파생됩니다. 메서드가 호출될 때 콘텐츠 유형을 알 수 없으면, set_boundary() 메서드는 이 에러를 발생시킵니다. Header는 특정 base64 디코딩 에러와 내장된 헤더를 포함하는 것으로 보이는 헤더를 만들려고 할 때 (즉, 연장 줄(continuation line)이어야 할 곳에 선행 공백이 없고 헤더처럼 보이는 것이 있을 때) 이 에러를 발생시킬 수 있습니다.

exception email.errors.BoundaryError

폐지되었고 더는 사용되지 않습니다.

exception email.errors.MultipartConversionError

Raised when a payload is added to a Message object using add_payload(), but the payload is already a scalar and the message’s Content-Type main type is not either multipart or missing. MultipartConversionError multiply inherits from MessageError and the built-in TypeError.

Since Message.add_payload() is deprecated, this exception is rarely raised in practice. However the exception may also be raised if the attach() method is called on an instance of a class derived from MIMENonMultipart (e.g. MIMEImage).

exception email.errors.HeaderWriteError

Raised when an error occurs when the generator outputs headers.

다음은 메시지를 구문 분석하는 동안 FeedParser가 찾을 수 있는 결함 목록입니다. 문제가 발견된 메시지에 결함이 추가됨에 유의하십시오. 그래서, 예를 들어, multipart/alternative 내에 중첩된 메시지에 잘못된 헤더가 있으면, 해당 중첩 메시지 객체가 결함을 갖게 되지만 포함하는 메시지는 그렇지 않습니다.

모든 결함 클래스는 email.errors.MessageDefect의 서브 클래스입니다.

  • NoBoundaryInMultipartDefect – A message claimed to be a multipart, but had no boundary parameter.

  • StartBoundaryNotFoundDefect – The start boundary claimed in the Content-Type header was never found.

  • CloseBoundaryNotFoundDefect – A start boundary was found, but no corresponding close boundary was ever found.

    버전 3.3에 추가.

  • FirstHeaderLineIsContinuationDefect – The message had a continuation line as its first header line.

  • MisplacedEnvelopeHeaderDefect - A “Unix From” header was found in the middle of a header block.

  • MissingHeaderBodySeparatorDefect - A line was found while parsing headers that had no leading white space but contained no ‘:’. Parsing continues assuming that the line represents the first line of the body.

    버전 3.3에 추가.

  • MalformedHeaderDefect – A header was found that was missing a colon, or was otherwise malformed.

    버전 3.3부터 폐지: 이 결함은 여러 파이썬 버전에서 사용되지 않았습니다.

  • MultipartInvariantViolationDefect – A message claimed to be a multipart, but no subparts were found. Note that when a message has this defect, its is_multipart() method may return False even though its content type claims to be multipart.

  • InvalidBase64PaddingDefect – When decoding a block of base64 encoded bytes, the padding was not correct. Enough padding is added to perform the decode, but the resulting decoded bytes may be invalid.

  • InvalidBase64CharactersDefect – When decoding a block of base64 encoded bytes, characters outside the base64 alphabet were encountered. The characters are ignored, but the resulting decoded bytes may be invalid.

  • InvalidBase64LengthDefect – When decoding a block of base64 encoded bytes, the number of non-padding base64 characters was invalid (1 more than a multiple of 4). The encoded block was kept as-is.

  • InvalidDateDefect – When decoding an invalid or unparsable date field. The original value is kept as-is.