DjangoBB LoFi version

Полная версия: Несколько вопросов про исключения.

Начало » Python для новичков » Несколько вопросов про исключения.

1 2 3

FishHook

Июль 2, 2020 11:00:28

ZerG
Вполне себе рабочая конструкция!

Рабочесть конструкции ИМХО обуславливается именно банальностью.
Как ты думаешь, в твоем примере выше 0x333 - это число? А 1e34 - число? Мы вряд ли ожидаем, что юзер знаком с синтаксисом питоньих литералов, поэтому логично предположить что этот ввод должен быть некорректным.

если мы перепишем пример вот так, например

 for i in range(0, 2):
    try:
        number = int(input(), 10)
    except:
        print("This is not number")

то это не то же самое, что было выше, потому что твой изначальный пример принимал float-ы, а этот нет.
То есть в более-менее небанальной реализации такой казалось бы простой задачи скорее всего придется валидировать именно строку.

ZerG

Июль 2, 2020 11:38:50

Тут вопрос не в длине чилса или его типе. А просто решение через try мы обрабатываем исключение.

py.user.next

Июль 3, 2020 01:20:48

Анализ ввода надо производить над введённой строкой. Сам питон может проверять недостаточно или, наоборот, перебарщивать с необходимым.

  
>>> int('-1')
-1
>>> int('-0001')
-1
>>> int('- 0001')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '- 0001'
>>> int('- 1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '- 1'
>>>

В общем, как показывает практика, ввод от пользователя всегда должен находиться под пристальным рассмотрением. Где-то это связано с тупостью пользователей, которые не могут ввести данные точно и из-за этого переносят негатив от своей неспособности на всю программу. Где-то это связано с чувствительностью данных, которые вводятся, с помощью которых суперумный пользователь проведёт инъекцию и получит все данные из базы данных системы и будет потом их продавать на чёрном рынке. Самое главное в этом всём то, что при проверке введённой строки определённым алгоритмом, мы его не меняем и он остаётся зафиксирован. И новая версия питона не изменит его. Если же мы полагаемся на чужой валидатор, то случайная ошибка в нём со стороны разработчиков валидатора, компрометирует нашу систему при автоматическом обновлении этого валидатора. То же самое произойдёт, если в валидаторе найдут уязвимость, неизвестную разработчикам валидатора, и не сообщат им о ней, а будут использовать на полную катушку.

Python_newbie13

Июль 4, 2020 03:17:27

Все стало еще не понятнее. Но мне к счастью не надо париться по поводу безопасности и т.п. Как пример
У меня есть алгоритм находящий корни уравнений. И мне эти корни надо проверить. Как пример
(x^2-1)/(x-1) = 0 алгоритм преобразует это x^2-1 = 0 и она даст 2 корня -1 и 1. Из них при проверке останется 1.

 try:
    проверка корня
 except ZeroDivisionError:
     удалить корень из списка

В таком варианте можно использовать исключения?

FishHook

Июль 4, 2020 16:47:38

Python_newbie13
В таком варианте можно использовать исключения?

Ну а почему вы не хотите сделать просто проверку на ноль перед делением?

Python_newbie13

Июль 5, 2020 05:53:40

Я не отрицаю, что можно сделать проверку. Но через исключения алгоритм проще. Однако, если это противоречит основным принципам, то естественно я сделаю через проверку и более сложный алгоритм, чем через кривой код. Мне надо понять: можно ли вообще использовать ради этого исключения или нет?

PEHDOM

Июль 5, 2020 10:28:42

Python_newbie13
В таком варианте можно использовать исключения?

да, вполне себе можно..

FishHook
Ну а почему вы не хотите сделать просто проверку на ноль перед делением?

ну дзен пайтона же: “лучше просить прощения чем разрешения” ИМХО такой подход как привел Python_newbie13 более pythonic-way.
Python_newbie13
Одна из причин, почему try..except поощряется в Python, заключается в том, что вы часто не можете предвидеть все способы использования своего кода, поэтому вместо проверки того, существует ли какое-то конкретное условие, может возникнуть определенный класс ошибок. Таким образом, try..except может сделать ваш код более многоразовым.
С другой стороны, когда вы“ запрашиваете разрешение”, вы должны выполнить дополнительную операцию, чтобы каждый раз запрашивать разрешение. Когда вы “просите прощения”, вам нужно только выполнять дополнительную операцию, например, когда она терпит неудачу.
То есть, если вы знаете что ошибка может возникнуть только в одном случае на миллион, то с точки зрения скорости выполнения лучше использовать try..except, а если у вас вероятность появления ошибки, скажем, процентов 70-90 то первоначальная проверка условий (“ запрашиваете разрешение”) может быть более выгодной по скорости.

FishHook

Июль 6, 2020 18:03:13

PEHDOM
ну дзен пайтона же: “лучше просить прощения чем разрешения” ИМХО такой подход как привел Python_newbie13 более pythonic-way.

Он не дал никакого конкретного алгоритма. Вот это

  try:
    проверка корня
 except ZeroDivisionError:
     удалить корень из списка

легко заменяется на вот это

  if x == 0:
    удалить корень из списка
 else:
    проверка корня

и я хоть убей не понимаю, почему исключения тут - боллее питоник. Хотите быть конкретными - давайте конкретные примеры. А в предложенном варианте - не убедительно.

Rodegast

Июль 6, 2020 20:50:16

> ну дзен пайтона же: “лучше просить прощения чем разрешения”

Это точно из “дзена”? Я не помню что там было что-то такое написано.

Python_newbie13

Июль 7, 2020 03:29:26

Попробую обьснить конкретнее. Я привел в пример уравнение:
(x^2-1)/(x-1) = 0
Сама проверка подставляет вместо значения х число и считает по алгоритму польской записи. Т.е мне придется дописать его, что бы выполнялось это условие. Более того, уравнение то может быть любым и при подстановкe давать разные ошибки например. arcos(100) даст value error и функций в математике, которые выдают ошибки при вводе них недопустимые значения, довольно много. Писать придется условия под каждую из них. Try except написать намного проще и быстрее чем прописывать критические условия под каждую функцию