Python: Як я можу знати, які винятки можуть бути викликані викликом методу

Чи є спосіб знати (під час кодування), яких винятків очікувати при виконанні коду python? У підсумку я вловлюю базовий клас винятків 90% часу, оскільки я не знаю, який тип винятків може бути викинутий (і не кажи мені читати документацію. Багато разів виняток можна поширити з глибини. І багато разів документація не оновлюється або не правильна). Чи є якийсь інструмент для перевірки цього? (наприклад, читаючи код python та бібліотеки)?

Думаю, рішення може бути лише неточним через відсутність статичних правил набору тексту.

Мені не відомий якийсь інструмент, який перевіряє винятки, але ви можете придумати власний інструмент, який відповідає вашим потребам (хороший шанс трохи пограти зі статичним аналізом).

З першої спроби ви можете написати функцію, яка будує AST, знаходить все Raise вузли, а потім намагається з'ясувати загальні закономірності створення винятків (наприклад, безпосередній виклик конструктора)

Нехай xбуде наступна програма:

x = '''\
if f(x):
    raise IOError(errno.ENOENT, 'not found')
else:
    e = g(x)
    raise e
'''

Складіть AST, використовуючи compilerпакет:

tree = compiler.parse(x)

Потім визначте Raiseклас відвідувача:

class RaiseVisitor(object):
    def __init__(self):
        self.nodes = []
    def visitRaise(self, n):
        self.nodes.append(n)

І пройдіться по збірних Raiseвузлах AST :

v = RaiseVisitor()
compiler.walk(tree, v)

>>> print v.nodes
[
    Raise(
        CallFunc(
            Name('IOError'),
            [Getattr(Name('errno'), 'ENOENT'), Const('not found')],
            None, None),
        None, None),
    Raise(Name('e'), None, None),
]

Ви можете продовжувати, вирішуючи символи за допомогою таблиць символів компілятора, аналізуючи залежності даних тощо. Або ви можете просто зробити висновок, що CallFunc(Name('IOError'), ...) "це однозначно повинно означати підвищення IOError", що цілком нормально для швидких практичних результатів :)

Ви повинні вловлювати лише ті винятки, з якими будете обробляти.

Ловити всі винятки за їх конкретними типами - нонсенс. Ви повинні зловити конкретні винятки ви можете і будете обробляти. За іншими винятками ви можете написати загальний улов, який вловлює "базовий виняток", реєструє його (використовуйте str()функцію) та припиняє роботу вашої програми (або робить щось інше, що підходить у аварійній ситуації).

Якщо ви дійсно збираєтеся впоратися з усіма винятками і впевнені, що жоден з них не є фатальним (наприклад, якщо ви запускаєте код у якомусь середовищі, яке знаходиться в ізольованому середовищі), то ваш підхід до пошуку загального BaseException відповідає вашим цілям.

Вас також може зацікавити посилання на мовні винятки , а не посилання на бібліотеку, якою ви користуєтесь.

Якщо посилання на бібліотеку дійсно погане, і воно не повторює власних винятків при лові системних, єдиним корисним підходом є запуск тестів (можливо, додати його до набору тестів, тому що якщо щось недокументоване, це може змінитися!) . Видаліть файл, який має вирішальне значення для вашого коду, і перевірте, який виняток створюється. Надайте занадто багато даних і перевірте, яку помилку це дає.

Вам все одно доведеться запускати тести, оскільки, навіть якщо метод отримання винятків за вихідним кодом існував, це не дасть вам уявлення про те, як слід обробляти будь-яке з них . Можливо, ви повинні показати повідомлення про помилку "Файл needful.txt не знайдено!" коли ловите IndexError? Тільки тест може сказати.

Правильним інструментом для вирішення цієї проблеми є unittests. Якщо у вас є винятки, викликані реальним кодом, які unittests не викликають, тоді вам потрібно більше unittests.

Розгляньте це

def f(duck):
    try:
        duck.quack()
    except ??? could be anything

качка може бути будь-яким предметом

Очевидно, ви можете мати AttributeErrorякщо качка не має шарлатана, TypeErrorякщо качка має шарлатан, але вона не викликається. Ти не уявляєш щоduck.quack() може підняти, можливо, навіть a DuckErrorчи щось інше

Тепер припустимо, у вас є такий код

arr[i] = get_something_from_database()

Якщо це підвищує IndexError ви не знаєте, чи воно походить від arr [i] чи глибоко всередині функції бази даних. зазвичай не так важливо, де стався виняток, а те, що щось пішло не так, і те, що ви хотіли, не сталося.

Зручна техніка полягає в тому, щоб зловити і, можливо, повторити такий виняток

except Exception as e
    #inspect e, decide what to do
    raise

Поки ніхто не пояснив, чому у вас не може бути повного, 100% правильного списку винятків, тому я вважав, що це варто прокоментувати. Однією з причин є першокласна функція. Скажімо, у вас є така функція:

def apl(f,arg):
   return f(arg)

Тепер aplможна підняти будь-який виняток, який fпіднімає. Хоча таких функцій у базовій бібліотеці не так багато, все, що використовує розуміння списку за допомогою користувацьких фільтрів, зіставлення, зменшення тощо.

Документація та аналізатори джерел є єдиними "серйозними" джерелами інформації тут. Тільки майте на увазі, що вони не можуть робити.

Я зіткнувся з цим при використанні сокета, я хотів з’ясувати всі умови помилок, в яких я б працював (отже, замість того, щоб намагатись створювати помилки та з’ясовувати, який сокет робить, я просто хотів стислий список). Зрештою, я закінчив grep'ing "/usr/lib64/python2.4/test/test_socket.py" для "підвищення":

$ grep raise test_socket.py
Any exceptions raised by the clients during their tests
        raise TypeError, "test_func must be a callable function"
    raise NotImplementedError, "clientSetUp must be implemented."
    def raise_error(*args, **kwargs):
        raise socket.error
    def raise_herror(*args, **kwargs):
        raise socket.herror
    def raise_gaierror(*args, **kwargs):
        raise socket.gaierror
    self.failUnlessRaises(socket.error, raise_error,
    self.failUnlessRaises(socket.error, raise_herror,
    self.failUnlessRaises(socket.error, raise_gaierror,
        raise socket.error
    # Check that setting it to an invalid value raises ValueError
    # Check that setting it to an invalid type raises TypeError
    def raise_timeout(*args, **kwargs):
    self.failUnlessRaises(socket.timeout, raise_timeout,
    def raise_timeout(*args, **kwargs):
    self.failUnlessRaises(socket.timeout, raise_timeout,

Що є досить стислим переліком помилок. Зараз, звичайно, це працює лише в кожному конкретному випадку і залежить від точності тестів (якими вони зазвичай є). В іншому випадку вам доведеться в значній мірі вловити всі винятки, зареєструвати їх та розібрати та зрозуміти, як з ними поводитися (що з модульним тестуванням не складе труднощів).

Є два способи, які я знайшов інформативними. Перший, запустіть код у iPython, який буде відображати тип виключення.

n = 2
str = 'me '
str + 2
TypeError: unsupported operand type(s) for +: 'int' and 'str'

По-друге, ми задовольняємось тим, що ловимо занадто багато, і з часом вдосконалюємось. Включіть tryвираз у свій код та catch except Exception as err. Надрукуйте достатньо даних, щоб знати, який виняток було створено. У міру виникнення винятків вдосконалюйте свій код, додаючи більш точне exceptречення. Якщо ви відчуваєте, що спіймали всі відповідні винятки, видаліть все включене. Хороша річ у будь-якому випадку, оскільки вона ковтає помилки програмування.

try:
   so something
except Exception as err:
   print "Some message"
   print err.__class__
   print err
   exit(1)

як правило, вам потрібно ловити виняток лише навколо декількох рядків коду. Ви не хотіли б розміщувати всю свою mainфункцію вtry except пункт. для кожних кількох рядків ви завжди повинні зараз (або мати можливість легко перевірити), який виняток може бути застосований.

документи мають вичерпний перелік вбудованих винятків . не намагайтеся, за винятком тих винятків, яких ви не очікуєте, вони можуть оброблятися / очікуватися у телефонному коді.

редагувати : те, що можна кинути, залежить, очевидно, від того, що ви робите! доступ до випадкового елемента послідовності:, IndexErrorвипадкового елемента dict: KeyErrorтощо.

Просто спробуйте запустити ці кілька рядків у IDLE та викликати виняток. Але unittest було б кращим рішенням, природно.