الاستثناءات المضمنة داخليًا في بايثون

يجب أن تكون جميع الاستثناءات في لغة بايثون مُنشأة من صنف مُشتق من الصنف BaseException. عند ذكر صنف مُحدد في جملة except خلال تعبير try، فإن جملة except تُعالج أي استثناء مُشتق من ذلك الصنف المُحدَّد (وليس الاستثناءات المُشتقة من الصنف الذي اُشتقت منه). إذا كان لدينا صنفا استثناءات غير مرتبطين بعلاقة وراثة فهما غير متماثلان حتى لو كانا بنفس الاسم.

من الممكن توليد الاستثناءات الداخلية المذكورة بالأسفل بواسطة مُفسر بايثون أو الدوال الداخلية.  تملك الاستثناءات "قيمة مرتبطة" تُشير بالتفصيل للسبب الرئيسي للخطأ إلا إذ ذُكِرَ خلاف ذلك. من الممكن أن تكون هذه القيمة عبارة عن نص أو صف (tuple) معلومات يتألف من عدة عناصر (مثال، رمز الخطأ ونص يصف الرمز). عادةً ما تُمرر القيمة المرتبطة كوسائط للدالة البانية لصنف الاستثناء.

من الممكن إطلاق الاستثناءات الداخلية خلال الشيفرة البرمجية بشكل مباشر. يُمكن استخدام ذلك لاختبار مُعالج استثناء أو لإبراز خطأ في شرط ما تمامًا كما في حالة قيام المُفسر بإطلاق  نفس الخطأ، ولكن يجب الانتباه الى أنه لا يوجد ما يمنع الشيفرة من إطلاق خطأ غير مناسب.

قد تُستخدم الاستثناءات الداخلية في تعريف استثناءات جديدة بواسطة وراثة الأصناف. يُنصح المبرمجون بأن يشتقوا استثناءاتٍ جديدةً من الصنف Exception أو أحد الأصناف الفرعية منه وليس من الصنف BaseException. مزيدٌ من المعلومات حول تعريف الاستثناءات متاحٌ في صفحة الاستثناءات المعرفة من طرف المستخدم.

عند إطلاق (أو إعادة إطلاق) استثناء ما في جملة except او finally فإن الخاصية __context__ ستُضبَط تلقائيًا إلى قيمة آخر استثناء مُلتقط، وإذا لم يُعالج ظهور استثناء جديد فإن نص سلسلة تتبع الاستثناءات (traceback) سيتضمن الاستثناءات المُسَببة بالإضافة للاستثناء الأخير.

عند إطلاق استثناء جديد (بدلًا من استخدام raise لإعادة إطلاق الاستثناء المُعالج حاليًا)، فإنه من الممكن إضافة السبب الصريح لسياق الاستثناء المُضمن من خلال استخدام جملة raise مع from بالشكل التالي:

raise new_exc from original_exc

في المثال التالي يتم إطلاق الاستثناء ArithmeticError في البداية، ولمّا كان الاستثناء ليس له استثناء مُسبب فسيكون السياق الخاص به المتمثل بالخاصية __context__ ذات قيمة None، بينما الاستثناء AsserionError تم إطلاقه باستخدام الجملة raise...from وتم تحديد الاستثناء الأول كمسبب له، لذلك فإن الخاصية __context__ للاستثناء AsserionError سيكون هو ArithmeticError، وعند طباعته ستظهر جملة الاستثناء y should not be equal to 2.

y = 2
try:
  if y==2:
    raise ArithmeticError("y should not be equal to 2")
except Exception as e1:
  print(e1.__context__)
  try:
    raise AssertionError("Assertion message") from e1
  except AssertionError as e2:
    print(e2.__context__)

التعبير الذي يلي كلمة from يجب أن يكون استثناءً أو القيمة None، إذ سيُضبَط قيمةً للخاصية __cause__ في الاستثناء الذي سيُطلَق. ستُضبَط قيمة الخاصية __suppress_context__ ضمنيًا لتأخذ القيمة True عند ضبط قيمة الخاصية __cause__ ، وبذلك فإن استخدام raise new_exc from None سيُبدِّل الاستثناء القديم إلى الجديد لأغراض العرض (مثال، تحويل الاستثناء KeyError إلى AttributeError بينما يُترك الاستثناء القديم متاحًا في الخاصية __context__ لأغراض الفحص في التنقيح).

تقوم سلسلة تتبع الاستثناءات (traceback) بعرض سلسلة الأخطاء التي تظهر بالإضافة للاستثناء نفسه. سَتُعرض سلسلة الاستثناء (traceback) الصريحة في الخاصية __cause__ دائمًا إذا كانت موجودة. لكن سَتُعرض سلسلة الاستثناء الضمنية في الخاصية __context__ إذا كانت قيمة الخاصية __cause__ هي None وقيمة الخاصية __suppress_context__ هي false.

بغض النظر عن أي حالة، سيُعرَض الاستثناء بعد أي سلسلة استثناءات بحيث يكون آخر سطر من سلسلة تتبع الاستثناء (traceback) هو سطر الاستثناء الذي تم إطلاقه.

الأصناف الأساسية

تُستخدم الاستثناءات التالية في الغالب كأصناف أساسية لاستثناءات أخرى في بايثون.

BaseException

الصنف الأساسي لكافة الاستثناءات الداخلية. ليس الهدف أن نرث منه مباشرةً بواسطة الأصناف المُعرفة من طرف المستخدم (عليك أن تستخدم لذلك الأمر الصنفَ Exception). إذا اُستدعيت الدالة str()‎ من قبل نُسخة من هذا الصنف، فسيتم إعادة معطيات النُسخة أو نص فارغ في حالة عدم وجود وسائط.

args

صف (tuple) من الوسائط المُمرَّرة للدالة البانية للاستثناء. بعض الاستثناءات المُضمَّنة مسبقًا في اللغة (مثل OSError) تتوقع عددًا مُحددًا من الوسائط، بينما الاستثناءات الأخرى تُستدعى في العادة باستخدام سلسلة نصية تُمثل رسالة الخطأ.

with_traceback(tb)‎

يعمل هذا التابع على جعل tb كسلسلة تتبع الاستثناء الجديدة (traceback) للاستثناء وتُعيد الكائن الذي يُمثل الاستثناء. ويُستخدم هذا التابع غالبًا في معالجة الاستثناء بالشكل التالي:

try:
    ...
except SomeException:
    tb = sys.exc_info()[2]
    raise OtherException(...).with_traceback(tb)

Exception

جميع الاستثناءات الداخلية واستثناءات non-system-exiting مُشتقة من هذا الصنف. جميع الاستثناءات المبنية من طرف المستخدم يجب أن تُشتق من هذا الصنف.

ArithmeticError

هذا الصنف هو أساس الاستثناءات الداخلية التي تُطلق عند حدوث الأخطاء الحسابية: OverflowError و ZeroDivisionError و FloatingPointError.

BufferError

يُطلق هذا الاستثناء اذا كانت هناك عملية لها علاقة بالذاكرة لا يُمكن تنفيذها.

LookupError

هذا الصنف هو الصنف الأساسي للاستثناءات التي تُطلق عندما يفشل استخدام مفتاح أو فهرس غير صالح في عملية ربط (mapping) أو في تسلسل (sequence):‏ IndexError و KeyError. يمكن أن يُطلق هذا الاستثناء مباشرةً باستخدام codecs.lookup()‎.

الاستثناءات العملية

تُطلق الاستثناءات التالية غالبًا في بايثون:

AssertionError

يُطلق هذا الاستثناء عندما يفشل تنفيذ جملة assert.

AttributeError

يُطلق هذا الاستثناء عند فشل ربط خاصية أو فشل الإشارة إليها (انظر الاشارة إلى الخاصيات).  سيُطلق الاستثناء TypeError عندما لا يدعم كائن ما الاشارة لخاصية أو ربط قيمة لها.

EOFError

يُطلق هذا الاستثناء عندما يتحقق شرط نهاية الملف EOF في الدالة input()‎. تُعيد التوابع io.IOBase.read()‎ و io.IOBase.readline()‎ نصًا فارغًا عند تحقق شرط نهاية الملف.

FloatingPointError

يُطلق عند فشل عملية حسابية لأرقام تحتوي على نقطة عائمة floating point. هذا الاستثناء مُعرف دائمًا، ولكنه يُطلق فقط عند ضبط بايثون مع الخيار ‎--with-fpectl، او عندما يُعرَّف الرمز WANT_SIGFPE_HANDLER في الملف pyconfig.h.

GeneratorExit

يطلق عند إغلاق مولد أو coroutine. انظر إلى generator.close()‎ و coroutine.close()‎. يرث هذا الاستثناء من الصنف BaseException بدلًا من Exception لأنه تقنيًا ليس بخطأ.

ImportError

يُطلق هذا الاستثناء عندما تواجه جملة الاستيراد import مشاكل في محاولة تحميل وحدة. بالإضافة لذلك، يُطلق الاستثناء عندما تحتوي جملة from ... import على اسم لا يمكن إيجاده.

يُمكن ضبط الخاصيات name و path كوسائط على شكل كلمات مفتاحية فقط (keyword-only arguments) إلى الدالة البانية للاستثناء. عند ضبطهما، فإن الاسم name يُمثل الوحدة التي فشل محاولة استيرادها، ويُمثل المسار path مسار الملف الذي أطلق الاستثناء.

ModuleNotFoundError

هذا الاستثناء هو صنف فرعي من ImportError ويُطلق بواسطة import عندما لا يُمكن تحديد مكان وحدة ما. يُطلق هذا الاستثناء أيضًا عندما تُوجد القيمة None في sys.modules.

هذا الاستثناء جديدٌ في نسخة بايثون 3.6.

IndexError

يُطلق هذا الاستثناء عند استخدام فهارس خارج النطاق. (تُعدل فهارس الاقتطاع تلقائيًا لتقع ضمن النطاق المسموح به؛ إذا كان الفهرس ليس رقمًا، فسيُطلق الاستثناء TypeError).

KeyError

يُطلق هذا الاستثناء عند استخدام مفتاح غير موجود ضمن مفاتيح قاموس ما.

KeyboardInterrupt

يُطلق هذا الاستثناء عند استعمال مُفتاح المقاطعة (interrupt key) (عادة Control-C أو Delete). تُنفذ فحوصات المقاطعة بشكل منتظم خلال عملية التنفيذ. يرث هذا الاستثناء من الصنف BaseException حتى لا يُلتقط من الشيفرة التي تلتقط الاستثناء Exception وبذلك يُمنع المفسر من الخروج.

MemoryError

يُطلق هذا الاستثناء عندما تَستهلك عمليةٌ ما الذاكرةَ مع إمكانية معالجة المشكلة بحذف بعض الكائنات. القيمة المرتبطة بهذا الاستثناء هي نص يشير الى نوعية العملية التي استهلكت الذاكرة. لاحظ أنه بسبب هيكلية إدارة الذاكرة الكامنة (الدالة malloc()‎ في لغة C)، فإن المُفسر قد لا يستطيع معالجة هذا الموقف بشكل كامل؛ ومع ذلك، سيُطلق المفسر استثناءً بحيث تُطبع سلسلة تتبع الاستثناءات (stack traceback) في حالة أن السبب هو برنامج طويل التنفيذ.

NameError

يُطلق هذا الاستثناء عندما لا يمكن إيجاد اسم عام أو محلي، وهذا ينطبق فقط على الأسماء غير المعرفة بشكل كامل (unqualified). القيمة المرتبطة بهذا الاستثناء هي رسالة خطأ تحتوي على الاسم الذي لا يمكن إيجاده.

NotImplementedError

يُشتق هذا الاستثناء من الصنف RuntimeError. يجب على التوابع المجردة (abstract) في الأصناف المُعرفة من قبل المستخدم إطلاق هذا الاستثناء عندما تتطلب الأصناف المُشتقة إعادة تعريف التابع، أو عندما يكون الصنف طُوِّرَ للإشارة الى أن تُضاف شيفرة الإعتماد (implementation).

ملاحظة: لا ينبغي استخدام الاستثناء للاشارة إلى أن عاملًا أو تابعًا ما ليسا للاستخدام؛ في هذه الحالة اترك العامل أو التابع دون تعريف، أو اضبطه إلى القيمة None (إذا كان صنفًا فرعيًا).

ملاحظة: لا يُستخدم الصنفان NotImplementedError و NotImplemented تبادليًا، حتى وإن كانا بأسماء وأغراض متشابهة، لمعرفة المزيد انظر الى توثيق الصنف NotImplemented.

OSError(errno, strerror[, filename[, winerror[, filename2]]])‎

يُطلق هذا الاستثناء عندما تُعيد دالة نظام خطأ له علاقة بالنظام، ويشمل ذلك فشل عمليات الإدخال/الإخراج مثل "الملف غير موجود" او "القرص ممتلئ" (غير مناسب لأنواع الوسائط غير الصحيحة أو الأخطاء العرضية).

الشكل الثاني من الدالة البانية تَضبط الخواص المتعلقة المشروحة بالأسفل. تُضبط الخاصيات بقيمة None عند عدم ذكرها.

للتوافقية الرجوعية (backwards compatibility)، إذا مُرِّرَت ثلاثة وسائط، فستحتوي الخاصية args على صفين (tuple) من أول وسيطين من الدالة البانية.

تُعيد الدالة البانية في العادة صنفًا فرعيًا من OSError، كما هو موضح في OSexception بالأسفل. يعتمد الصنف الفرعي المحدد على القيمة النهائية للقيمة errno. يحدث ذلك فقط عند بناء OSError مباشرةً أو باستخدام اسم بديل (alias)، ولم يُرث خلال تصنيف فرعي.

errno

رمز خطأ رقمي من متغير C باسم errno.

winerror

في نظام ويندوز، يعطيك هذا رقم الخطأ المحلي (native error code) على مستوى النظام. أما في معايير POSIX، الخاصية errno هي ترجمة تقريبية للخطأ المحلي.

في نظام ويندوز، إذا كان الوسيط winerror رقمًا، فإن الخاصية errno تُحدد من رقم الخطأ الخاص بنظام ويندوز، ويُتجاهل الوسيط errno. أما في البيئات الأخرى، فسيُتجاهل الوسيط winerror، والخاصية winerror لن تكون موجودةً.

Strerror

رسالة الخطأ التي زودها نظام التشغيل. تُنسق رسالة الخطأ بواسطة الدالة perror()‎ في لغة السي في أنظمة POSIX، وبواسطة الدالة FormatMessage()‎ في نظام الويندوز.

filename2

في الاستثناءات التي تنطوي على مسار ملف في النظام، الخاصية filename هي اسم الملف المُمَر لدوال مثل open()‎ و os.unlike()‎.

للدوال التي تحتوي على مسارَي ملف مثل os.rename()‎، ستُمثِّل الخاصية filename2 اسم الملف الثاني المُمَر للدالة.

التغييرات التي حدثت في إصدار بايثون 3.3: الاستثناءات EnvironmentError و IOError و WindowsError و socket.error و select.error و mmap.error دُمجت في OSError، والدالة البانية قد تُعيد صنف فرعي.

التغييرات التي حدثت في إصدار بايثون 3.4: الخاصية filename أصبحت الاسم الأصلي للملف المُمَرر للدالة، بدلًا من الاسم المُرَمز/مفكوك-ترميزه من ترميز ملف النظام. بالإضافة لذلك، أُضيف الوسيط والخاصية filename2.

OverflowError

يُطلق هذا الاستثناء عندما تكون نتيجة عملية حسابية كبيرة جدًا بحيث لا يمكن تمثيلها. لا يمكن أن يحدث ذلك للأرقام الصحيحة integers (يُطلق الاستثناء MemoryError لذلك). على الرغم من ذلك ولأسباب تاريخية، يُطلق الخطأ OverflowError في بعض الأحيان للأرقام الصحيحة التي هي خارج نطاق المطلوب. أغلب العمليات الحسابية التي تحتوي على النقطة العائمة لا تُفحص بسبب عدم وجود معيار حاكم لاستثناءات الأعداد ذات النقطة العائمة في معالجة الاستثناء في لغة C.

RecursionError

هذا الاستثناء مُشتق من الصنف RuntimeError، ويطلق عندما يكتشف المفسر أن العمق الأعلى للاستدعاء التعاودي (recursion depth) تم تجاوزه (انظر الى sys.getrecursionlimit()‎).

هذا الاستثناء جديدٌ في بايثون 3.5: في السابق كان يُطلَق الاستثناء RuntimeError.

ReferenceError

يُطلق هذا الاستثناء عندما يُستخدم وكيل إشارة ضعيف (weak reference proxy) مُنشأ باستخدام الدالة weakref.proxy()‎ في الوصول لخاصية في الكائن المشار إليه في الخطأ بعد أن يكون جُمع في القمامة. لمعلومات أكثر عن التأشير الضعيف انظر الى الوحدة weakref.

RuntimeError

يُطلق هذا الاستثناء عندما يُكتشف خطأٌ ما لا يقع ضمن أي تصنيفات أخرى. القيمة المرتبطة هي نص يشير لماذا حدث الخطأ على وجه التحديد.

StopIteration

يُطلق بواسطة الدالة الداخلية next()‎ وتابع المُكَرِر ‎__next__()‎ للإشارة أنه لا يوجد عناصر أخرى يمكن إنتاجها باستخدام المُكَرِر. كائن الاستثناء يملك خاصية وحيدة value،  وتُمرر كوسيط عند بناء الاستثناء وتأخذ قيمة None. عندما تعود دالة المولد أو coroutine، تُطلق نسخة من الاستثناء StopIteration، والقيمة المُعادة من الدالة تُستخدم كمعامل value للدالة البانية للاستثناء.

اذا عُرفت دالة المولد في حضور الموجه from __future__ import generator_stop فهذا سيطلق StopIteration، وسيحول الى RuntimeError (مُحتفظًا بالاستثناء StopIteration كمسبب للاستثناء الجديد).

التغييرات في إصدار بايثون 3.3: أُضيفت الخاصية value مع جعل دوال المولد تستخدمها لتعيد قيمة.

التغييرات في إصدار بايثون 3.5: قُدم التحويل للخطأ RuntimeError.

StopAsyncIteration

يجب أن يُطلق بواسطة التابع ‎__anext__()‎ الخاص بكائن المكرر غير المتزامن (asynchronous iterator) لإيقاف التكرار.

هذا الاستثناء جديدٌ في بايثون 3.5

SyntaxError

يُطلق عندما يكتشف المُفسِّر (parser) خطأً في الصيغة. قد يحدث ذلك في جملة الاستيراد، أو في استدعاء الدوال الداخلية exec()‎ أو eval()‎، أو عند قراءة ملف السكربت أو مجرى الدخل القياسي.

نُسخ هذا الصنف تمتلك الخواص filename و lineno و offset و text لوصول أسهل للتفاصيل. يعيد التابع str()‎ في الاستثناء الرسالة فقط.

IndentationError

الصنف الأساسي لأخطاء الصيغة المتعلقة بالإزاحة غير الصحيحة. هذا الاستثناء هو صنف فرعي من الصنف SyntaxError.

TabError

يُطلق عندما تحتوي الإزاحة على فراغات وعلامات جدولة متعارضة. هذا الاستثناء هو صنف فرعي من IndentationError.

SystemError

يُطلق عندما يجد المُفسر خطأً داخليًا، ولكن الموقف لا يبدو عليه خطيرًا لدرجة فقدان الأمل. القيمة المرتبطة هي نص يشير إلى ما حدث من خطأ. يجب عليك تبليغ المسؤول عن صيانة ومتابعة مُفسر لغة بايثون المُثبّت لديك. تأكد من ذكر رقم نسخة مُفسر بايثون (يمكنك الحصول عليه من الخاصية sys.version ؛ تُطبع رقم النسخة أيضًا عن تشغيل جلسة بايثون تفاعلية) ورسالة الخطأ وإن أمكن مصدر البرنامج الذي أطلق الخطأ.

SystemExit

يُطلق هذا الاستثناء بواسطة الدالة sys.exit()‎. يرث هذا الصنف من BaseException بدلًا من Exception حتى لا يُلتقط من الشيفرة التي تُعالج الاستثناء Exception. هذا يسمح للاستثناء بالانتشار (propagate) بطريقة مناسبة وينهي تنفيذ المُفسر.

عندما لا يُعالج الاستثناء، فسينتهي تنفيذ مُفسر بايثون، ولا تُطبع سلسلة تتبع الاستثناءات (stack traceback). تقبل الدالة البانية نفس الوسيط المُمَرر للدالة sys.exit()‎. إذا كانت القيمة رقم صحيح، تُحدد حالة خروج النظام (المُمَررة للدالة exit()‎ في لغة C)؛ إذا كانت None، فستأخذ حالة خروج النظام القيمة 0 وإذا كانت نوع آخر مثل سلسلة نصية، فستُطبع قيمة الكائن وتصبح حالة خروج النظام 1.

يُحَوَّل استدعاء الدالة sys.exit()‎ إلى استثناءٍ حتى تُنفذ معالجات الخطأ (جملتي finally و try )، وحتى يُمكن للمنقح (debugger) تنفيذ سكربت ما دون فقدان التحكم في تنفيذه. من الممكن استخدام الدالة os._exit()‎ إذا كان من الضرورة القصوى الخروج حالًا (مثل الخروج من عملية ابن للعملية الحالية بعد استدعاء os.fork()‎).

code

حالة الخروج أو رسالة الخطأ المُمَررة للدالة البانية (القيمة التلقائية هي None).

TypeError

يُطلق عندما تُطبق دالة أو عملية على كائن من نوع غير مناسب. القيمة المرتبطة هي سلسلةٌ نصيةٌ تُعطي تفاصيل عدم تطابق النوع.

قد يُطلق هذا الاستثناء بواسطة شيفرة المستخدم مباشرةً للإشارة لعدم قابلية إجراء عملية على كائن. إذا كان الكائن يدعم إجراء عملية معينة لكنها غير مبرمجة بعد، فإن الاستثناء الأفضل لذلك هو NotImplementedError.

تمرير وسائط ذات أنواع غير صحيحة (مثل تمرير قائمة [list] والمتوقع هو رقم صحيح) يجب أن يطلق الاستثناء TypeError، ولكن تمرير وسائط بقيم غير صحيحة (مثل تمرير رقم خارج الحدود المتوقعة) يجب أن يُطلق الاستثناء ValueError.

UnboundLocalError

يُطلق عندما يُشار إلى متغير محلي في دالة أو تابع ولكن لم تعطَ قيمةٌ لهذا المتغير بعد. هذا الاستثناء هو صنف فرعي من NameError.

UnicodeError

يُطلق هذا الاستثناء عند حدوث خطأ ترميز أو فك ترميز يتعلق بيونيكود؛ وهو صنف فرعي من الصنف ValueError.

يمتلك هذا الاستثناء خاصيات تشرح خطأ الترميز أو فك الترميز. فمثلًا، err.object[err.start:err.end]‎ يعطي المُدخل غير الصالح الذي فشل عنده الترميز.

encoding

اسم الترميز الذي أطلق الخطأ.

reason

نص يصف خطأ الترميز بالتفصيل.

object

الكائن الذي تم محاولة ترميزه أو فك ترميزه.

start

الفهرس الأول للبيانات غير الصالحة في الكائن.

end

الفهرس بعد آخر بيانات غير الصالحة.

UnicodeEncodeError

يُطلق عند حدوث خطأ ترميز. وهو صنف فرعي من UnicodeError.

UnicodeDecodeError

يُطلق عند حدوث خطأ فك ترميز. وهو صنف فرعي من UnicodeError.

UnicodeTranslateError

يُطلق عند حدوث خطأ ترميز خلال عملية التحويل. وهو صنف فرعي من UnicodeError.

ValueError

يُطلق عندما تتسلم عملية داخلية أو دالة وسيط بنوع صحيح ولكن بقيمة غير مناسبة، ولا يوجد معلومات أكثر عن الخطأ من قبيل ظهور الاستثناء IndexError مثلًا.

ZeroDivisionError

يُطلق عندما يكون الوسيط الثاني من عملية القسمة أو باقي القسمة هو صفر. القيمة المرتبطة هي نص يشير إلى نوع القيم التي تجرى عليها العملية والعملية.

الاستثناءات التالية بقيت من أجل التوافقية مع نُسخ بايثون السابقة، ابتداءً من بايثون 3.3، تُعتبر أسماءً بديلةً (aliases) للاستثناء OSError.

WindowsError

متاحةٌ في نظام الويندوز فقط.

استثناءات نظام التشغيل

الاستثناءات التالية هي أصناف فرعية من الاستثناء OSError وتُطلق بناءً على رقم الخطأ الصادر من النظام.

BlockingIOError

يُطلق عندما يُحجز كائنٌ (مثل socket) من قبل عملية ما ويكون هذا الكائن مضبوطًا لعملية غير حاجزة (non-blocking). يرتبط هذا الاستثناء بأرقام الأخطاء التالية: EAGAIN و EALREADY و EWOULDBLOCK و EINPROGRESS.

بالاضافة لما تملكه الاستثناءات OSError و BlockingIOError من خاصيات، توجد خاصية واحدة إضافية وهي:

characters_written

هو رقم صحيح يحتوي على عدد المحارف التي كتُبت في stream من قَبل حجزها. هذه الخاصية متاحة عند استخدام أصناف عمليات الإدخال والإخراج المحفوظة في الذاكرة المؤقتة والموجودة في وحدة io.

ChildProcessError

يُطلق هذا الاستثناء عندما يفشل إجراء ما في عملية ابن (child process). يرتبط هذا الاستثناء برقم الخطأ ECHILD.

ConnectionError

الصنف الأساسي للقضايا المتعلقة بالاتصال. الأصناف الفرعية من هذا الاستثناء هي BrokenPipeError و ConnectionAbortedError و ConnectionRefusedError  و ConnectionResetError.

BrokenPipeError

هذا الاستثناء هو صنف فرعي من ConnectionError، ويُطلق عند محاولة الكتابة في أنبوب (pipe) بينما تكون نهايته قد أُغلقت، أو عند محاولة الكتابة في socket قد تم وقف الكتابة فيها. يرتبط هذا الاستثناء بأرقام الخطأ EPIPE و ESHUTDOWN.

ConnectionAbortedError

هذا الاستثناء هو صنف فرعي من ConnectionError، ويُطلق عندما تُحبَط محاولة الاتصال من قبل الطرف الأخر. يرتبط هذا الاستثناء برقم الخطأ ECONNABORTED.

ConnectionRefusedError

هذا الاستثناء هو صنف فرعي من ConnectionError، ويُطلق عندما تُرفض محاولة الاتصال من الطرف الأخر. يرتبط هذا الاستثناء برقم الخطأ ECONNREFUSED.

ConnectionResetError

هذا الاستثناء هو صنف فرعي من ConnectionError، ويُطلق عندما يُعاد ضبط الاتصال من الطرف الأخر. يرتبط هذا الاستثناء برقم الخطأ ECONNRESET.

FileExistsError

يُطلق عند محاولة إنشاء ملف أو مجلد موجود مُسبقًا. يرتبط هذا الاستثناء برقم الخطأ EEXIST.

FileNotFoundError

يطلق هذا الاستثناء عندما يُطلب ملف أو مجلد ولكنه غير موجود. يرتبط هذا الاستثناء برقم الخطأ ENOENT.

InterruptedError

يطلق هذا الاستثناء عند مقاطعة إستدعاء ما من قبل النظام بواسطة إشارة قادمة (incoming signal). يرتبط هذا الاستثناء برقم الخطأ EINTR.

التغييرات في إصدار بايثون 3.5: تُعيد بايثون استدعاءات النظام عندما تُقاطَع باستخدام إشارة قادمة، إلا إذا أَطلق مُعالج الإشارة استثناءً.

IsADirectoryError

يُطلق عندما تطلب دالةٌ تجري عمليةً على ملفٍ ما (مثل os.remove()‎) مجلدًا ما. يرتبط هذا الاستثناء برقم الخطأ EISDIR.

NotADirectoryError

يُطلق عندما تُستدعى دالةٌ تجري عمليةً على مجلدٍ ما (مثل (os.listdir(‎) على متغير أو مُعَرف ليس بمجلد. يرتبط هذا الاستثناء برقم الخطأ ENOTDIR.

PermissionError

يطلق عند محاولة تشغيل عملية دون وجود صلاحيات الوصول المناسبة لذلك، مثل أذونات ملفات النظام. يرتبط هذا الاستثناء برقم الخطأ EACCES و EPERM.

ProcessLookupError

يطلق عندما تكون العملية المُمَرَّرة غير موجودة. يرتبط برقم الخطأ ESRCH.

TimeoutError

يُطلق عندما تنتهي مدة صلاحية دالة نظام على مستوى النظام. يرتبط هذا الاستثناء برقم الخطأ  ETIMEDOUT.

جميع الاستثناءات السابقة أُضيفت في بايثون 3.3 وهي أصناف فرعية من الصنف OSError.

التحذيرات

تُستخدم الاستثناءات التالية كتحذيرات، انظر للوحدة warnings لمزيد من المعلومات.

Warning

الصنف الأساسي لاستثناءات التحذيرات.

UserWarning

الصنف الأساسي للتحذيرات التي تُوَلدها شيفرة المستخدم.

DeprecationWarning

الصنف الأساسي لتحذيرات الميزات المُهملة (deprecated features).

PendingDeprecationWarning

الصنف الأساسي لتحذيرات الميزات التي ستُهمل في المستقبل.

SyntaxWarning

الصنف الأساسي للتحذيرات الخاصة بالصيغ المشكوك في صحتها.

RuntimeWarning

الصنف الأساسي للتحذيرات التي تظهر أثناء تنفيذ الشيفرة البرمجية.

FutureWarning

الصنف الأساسي للتحذيرات الخاصة بالدوال البانية التي ستتغير لُغويًا في المستقبل.

ImportWarning

الصنف الأساسي للتحذيرات الخاصة بالأخطاء المُحتملة أثناء استيراد الوحدات.

UnicodeWarning

الصنف الأساسي للتحذيرات الخاصة بالترميز.

BytesWarning

الصنف الأساسي للتحذيرات الخاصة بالنوعين bytes و bytearray.

ResourceWarning

الصنف الأساسي للتحذيرات الخاصة بحجم استخدام مصدر ما.

هذا الاستثناء جديدٌ في بايثون 3.2.

مصادر

• صفحة Built-in Exceptions في توثيق بايثون الرسمي.