Где стандартный список исключений python для программ для повышения?

Ответ 1

Если ошибка соответствует описанию одного из стандартных классов исключений python, то, во что бы то ни стало, выбросите его.

Общими для использования являются TypeError и ValueError, список, к которому вы уже привязаны, является стандартным списком.

Если вы хотите иметь специфичные для приложения, то альтернатива Subclassing Exception или один из его потомков - это путь.

Чтобы ссылаться на примеры, приведенные в .NET. ApplicationException ближе всего к RuntimeError ArgumentNullException, вероятно, будет AttributeError (попробуйте и вызовите метод, который вы хотите, пусть python создает исключение a la duck typing) AttributeOutOfRange является более конкретным ValueError InvalidOperationException может быть любое количество примерно эквивалентных исключений, входящих в стандартную библиотеку python.

В принципе, выберите тот, который отражает любую ошибку, которую вы поднимаете, основываясь на описаниях на странице http://docs.python.org/library/exceptions.html.

Ответ 2

Во-первых, Python повышает стандартные исключения для вас.

Лучше попросить прощения, чем спросить разрешения

Просто попробуйте выполнить операцию и пусть Python создает исключение. Не скопируйте все с помощью if would_not_work(): raise Exception. Никогда не стоит писать. Python уже делает это в случаях all.

Если вы думаете, что вам нужно поднять стандартное исключение, вы, вероятно, пишете слишком много кода.

Возможно, вам придется поднять ValueError.

def someFunction( arg1 ):
    if arg1 <= 0.0:
        raise ValueError( "Guess Again." )

Время от времени вам может понадобиться поднять TypeError, но это редко.

def someFunctionWithConstraints( arg1 ):
    if isinstance(arg1,float):
         raise TypeError( "Can't work with float and can't convert to int, either" )
    etc.

Во-вторых, вы почти всегда хотите создавать свои собственные уникальные исключения.

 class MyException( Exception ): 
     pass

Это все, что требуется для создания чего-то уникального и уникального для вашего приложения.

Ответ 3

Кажется, я вспоминаю, что я обучен документацией, что нормально поднять предопределенные исключения, если они уместны. Например, рекомендуемый способ завершения работы - это больше не вызывать exit(), а скорее для повышения эффективности SystemExit.

Другой пример - повторное использование исключения IndexError в пользовательских типах контейнеров.

Конечно, ваше приложение должно определять свои собственные исключения, а не фактически переустанавливать системные исключения. Я просто говорю, что нет запрета на повторное использование их там, где это необходимо.

Ответ 4

Путь Pythonic просто позволяет исключениям проходить через сам Python. Например, вместо:

def foo(arg):
  if arg is None:
    raise SomeNoneException
  bar = arg.param

Просто выполните:

def foo(arg):
  bar = arg.param

Если arg есть None или не имеет атрибута param, вы получите исключение из самого Python.

В Python glossary это называется "EAFP":

Легче просить прощения, чем разрешения. Это общее кодирование Python стиль предполагает существование действительных ключи или атрибуты и уловы если предположение доказывает ложный. Этот чистый и быстрый стиль характеризуется наличием многих попробуйте и за исключением утверждений. техника контрастирует с LBYL (Look Before You Leap) стиль, общий для многих других языков таких как C.

И он хорошо работает в тандеме с философией философии утиного языка у Python.

Это не значит, что вы не должны создавать собственные исключения, конечно же, просто вам не нужно обертывать уже существующие исключения Python.

Для ваших собственных исключений создайте классы, полученные из Exception, и бросьте их, когда они подходят.