Вы обрабатываете события, где поле utm_source может отсутствовать, и это нормально. Какой подход обычно лучше, чем ловить KeyError ради значения по умолчанию?
AИспользовать
event.get('utm_source', 'unknown'), чтобы получить дефолт без исключения.BВсегда делать
event['utm_source'] и оборачивать весь пайплайн в except Exception:.CПринудительно превращать событие в строку через
str(event) и искать подстроку.DИспользовать
raise KeyError('utm_source'), чтобы заполнить дефолт.Правильный ответ. Если отсутствие ключа ожидаемо, удобнее
dict.get(...), чем try/except KeyError.Разбор
Исключения подходят для действительно исключительных ситуаций. Если поле может отсутствовать по данным, event.get('utm_source', 'unknown') делает намерение ясным, упрощает код и уменьшает «шум» в отладке. KeyError полезен, когда ключ обязан быть и его отсутствие — ошибка контракта.
Проверь себя · 1/3разбор после ответа
Вы читаете сумму из CSV как строку
value = '3.14' и пытаетесь сделать int(value). Что произойдёт?Ещё вопросы по теме «Исключения и отладка»
- В обработчике данных вы используете конструкцию `try`/`except`/`finally`. Внутри `try` происходит ошибка, она поймана в `except`. Что произойдёт с кодом в `finally`?
- Вы парсите событие в словарь `event`. Что произойдёт при обращении `event["currency"]`, если ключа `currency` в словаре нет?
- В отчёте вы считаете сумму и случайно складываете число и строку: `total + "10"`. Какое исключение наиболее вероятно?
- Скрипт получает список строк, но иногда он короче ожидаемого. Что произойдёт при обращении `rows[3]`, если в списке всего 3 элемента?
- Вы пишете функцию, которая внутри `try` делает `return`, а в `finally` закрывает ресурс (например, файл или соединение). Что произойдёт с кодом в `finally` при `return` из `try`?
- Все вопросы по «Исключения и отладка» →