email.Errors モジュールでは、
以下の例外クラスが定義されています:
-
これは email パッケージが発生しうるすべての例外の基底クラスです。
これは標準の Exception クラスから派生しており、
追加のメソッドはまったく定義されていません。
-
これは Parser クラスが発生しうる例外の基底クラスです。
MessageError から派生しています。
-
メッセージの RFC 2822 ヘッダを解析している途中にある条件でエラーがおこると発生します。
これは MessageParseError から派生しています。
この例外が起こる可能性があるのは Parser.parse() メソッドと
Parser.parsestr() メソッドです。
この例外が発生するのはメッセージ中で最初の RFC 2822 ヘッダが現れたあとに
エンベロープヘッダが見つかったとか、最初の RFC 2822 ヘッダが現れる前に
前のヘッダからの継続行が見つかったとかいう状況を含みます。
あるいはヘッダでも継続行でもない行がヘッダ中に見つかった場合でも
この例外が発生します。
-
メッセージの RFC 2822 ヘッダを解析している途中にある条件でエラーがおこると発生します。
これは MessageParseError から派生しています。
この例外が起こる可能性があるのは Parser.parse() メソッドと
Parser.parsestr() メソッドです。
この例外が発生するのは、厳格なパーズ方式が用いられているときに、
multipart/* 形式の開始あるいは終了の文字列が見つからなかった場合などです。
| 例外 MultipartConversionError( |
) |
-
この例外は、
Message オブジェクトに add_payload() メソッドを使って
ペイロードを追加するとき、そのペイロードがすでに単一の値である
(訳注: リストでない) にもかかわらず、そのメッセージの
ヘッダのメインタイプがすでに設定されていて、それが multipart 以外になって
しまっている場合にこの例外が発生します。
MultipartConversionError は MessageError と
組み込みの TypeError を両方継承しています。
Message.add_payload() はもはや推奨されないメソッドのため、
この例外はふつうめったに発生しません。しかしこの例外は
attach() メソッドが MIMENonMultipart から
派生したクラスのインスタンス (例: MIMEImage など) に対して
呼ばれたときにも発生することがあります。
以下は FeedParser がメッセージの解析中に検出する障害 (defect) の一覧です。
注意: これらの障害は、問題が見つかったメッセージに追加されるため、たとえば
multipart/alternative 内にあるネストしたメッセージが
異常なヘッダをもっていた場合には、そのネストしたメッセージが障害を
持っているが、その親メッセージには障害はないとみなされます。
すべての障害クラスは email.Errors.MessageDefect のサブクラスですが、
これは例外とは違いますので注意してください。
バージョン 2.4 で 新たに追加 された仕様:
All the defect classes were added
- NoBoundaryInMultipartDefect - メッセージが multipart だと宣言されているのに、
boundary パラメータがない。
- StartBoundaryNotFoundDefect - ヘッダで宣言された
開始境界がない。
- FirstHeaderLineIsContinuationDefect - メッセージの最初のヘッダが
継続行から始まっている。
- MisplacedEnvelopeHeaderDefect - ヘッダブロックの途中に ``Unix From'' ヘッダがある。
- MalformedHeaderDefect - コロンのないヘッダがある、あるいはそれ以外の異常なヘッダである。
- MultipartInvariantViolationDefect - メッセージが multipart だと
宣言されているのに、サブパートが存在しない。注意: メッセージがこの障害を持っているとき、
is_multipart() メソッドは たとえその content-type が multipart であっても
false を返すことがあります。
ご意見やご指摘をお寄せになりたい方は、 このドキュメントについて... をご覧ください。
