# `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.

exception email.errors.MessageDefect

  이메일 메시지를 구문 분석할 때 발견되는 모든 결함에 대한 베이스 클래스입니다. `ValueError`에서 파생됩니다.

exception email.errors.HeaderDefect

  이메일 헤더를 구문 분석할 때 발견되는 모든 결함에 대한 베이스 클래스입니다. `MessageDefect`에서 파생됩니다.

다음은 메시지를 구문 분석하는 동안 `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.