Найти - Пользователи
Полная версия: И снова про исключения.
Начало » Python для экспертов » И снова про исключения.
1
ice
Недавно столкнулся с такой задачей (спрашивал в джаббере):

    def get_user_data(self, key, default = None):
if isinstance(self.user_data, dict):
return self.user_data.get(key, default)
else:
return default
то есть есть некий член класса - user_data. user_data может быть любым типом.

Он может быть словарем, а может и не быть словарем, но иметь обработчик __getitem__ в этом обработчике он может генерить любое исключение. Мне нужно попытаться получить элемент key из user_data и в случае исключения вернуть default. Проблема в том, что код, который выше работает только с user_data, если он словарь или произошел от словаря, но не работает с самодельными классами.

Самодельный класс может генерить исключение KeyError и много других, например AccessDeny (если это класс для работы с FS) или NetError (если это класс для работы с сетью), ResourceError (для работы с галереей) и тд. Как все это учесть, учесть ЛЮБОЕ исключение, коих могут быть сотни?

единственный вариант, который я нашел – это ловить ВСЕ исключения (try: except:), что не хорошо. И как быть?
Александр Кошелев
Так генерация KeyError при отсутсвии ключа у user_data должно быть контрактом и не имеет значения что это за объект на самом деле. Иначе это не утка.

Т.е. понимаете, вы хотите обработать исключение (причем любое) на том уровне абстракции, когда вы уже о нем практически ничего не знаете. А это ошибка. Поэтому KeyError как результат __getitem__ должен быть частью интерфейса.
ice
А если этому классу нужно вернуть другое исключение? КейЕррор возвращается когда ключа нет, А если ключ есть, но (как пример) ресурс недоступен?
Александр Кошелев
ice
А если этому классу нужно вернуть другое исключение? КейЕррор возвращается когда ключа нет, А если ключ есть, но (как пример) ресурс недоступен?
В таком случае можно бросать тот же KeyError но с описанием конретной случившийся ошибки.

Вообще странно что у вас возникла такая проблема. Если вы знаете все возможные варианты поведения user_data, тогда что вам мешает их все предусмотреть и соответственно обработать. Но в таком случае, с ещё большим успехом можно вынести обработку этих ситуаций в сам объект user_data.

Тут на лицо ошибка проектирования.
ice
Если вы знаете все возможные варианты поведения user_data
Его может и другой пользователь написать. остановлюсь на контракте.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB