当前位置: 首页 > 面试题库 >

python中的嵌套try / except块是一种好的编程习惯吗?

卢作人
2023-03-14
问题内容

我正在编写自己的容器,该容器需要通过属性调用来访问内部的字典。容器的典型用法如下:

dict_container = DictContainer()
dict_container['foo'] = bar
...
print dict_container.foo

我知道写这样的东西可能很愚蠢,但这就是我需要提供的功能。我正在考虑通过以下方式实现此目的:

def __getattribute__(self, item):
    try:
        return object.__getattribute__(item)
    except AttributeError:
        try:
            return self.dict[item]
        except KeyError:
            print "The object doesn't have such attribute"

我不确定嵌套的try / except块是否是一个好习惯,所以另一种方法是使用hasattr()and has_key()

def __getattribute__(self, item):
        if hasattr(self, item):
            return object.__getattribute__(item)
        else:
            if self.dict.has_key(item):
                return self.dict[item]
            else:
                raise AttributeError("some customised error")

或者使用其中之一,然后尝试使用catch块,如下所示:

def __getattribute__(self, item):
    if hasattr(self, item):
        return object.__getattribute__(item)
    else:
        try:
            return self.dict[item]
        except KeyError:
            raise AttributeError("some customised error")

哪个选项最适合pythonic和优雅?


问题答案:

您的第一个例子很好。甚至官方的Python文档也推荐这种称为EAFP的样式。

就个人而言,我宁愿避免在不必要时嵌套:

def __getattribute__(self, item):
    try:
        return object.__getattribute__(item)
    except AttributeError:
        pass  # fallback to dict
    try:
        return self.dict[item]
    except KeyError:
        raise AttributeError("The object doesn't have such attribute") from None

PS。has_key()已在Python 2中弃用了很长时间。请item in self.dict改用。



 类似资料:
  • 问题内容: 我设法定义一个类A,使用另一个类B的实例列表作为类A的实例变量。B类具有更改A类的另一个实例变量a1的功能。类A还具有更改类B的实例变量bb的功能。因此,A类可以访问B类,而B类可以访问A类。这两个类嵌套在一起。我知道我们可以简化将B类的所有实例变量和函数更改为A类的事情。但是在我的项目中,这种嵌套结构才是真正的东西。 我想知道的是,这种嵌套类是否会降低python的效率?有更好的解决

  • 本文向大家介绍django中嵌套的try-except实例,包括了django中嵌套的try-except实例的使用技巧和注意事项,需要的朋友参考一下 我就废话不多说了,大家还是直接看代码吧! 感觉上面这段代码,应用的技术点蛮多的,作个记录。 包括其node port的管理思想,提取技巧。 orm的列表扁平化,列表交集,批量删除 补充知识:Django 在异常捕获中进行数据库保存,保存后将异常再抛

  • 问题内容: 我经常看到有关不鼓励使用的其他问题的评论。为什么这样不好?有时我只是不在乎错误是什么,我只想继续编写代码。 为什么使用积木不好?是什么让它不好?是我pass出错还是我except出错了? 问题答案: 正如你正确猜到的那样,它有两个方面:通过在后面不指定任何异常类型来捕获任何错误,并在不采取任何操作的情况下简单地传递它。 我的解释要“长一点”,因此; 可以细分为: 不要发现任何错误。始终

  • 问题内容: 我发现了这种模式(或反模式),对此我感到非常满意。 我觉得它非常敏捷: 有时我用它的表弟: 我不需要创建人为的元组并计算参数并将%s匹配位置保留在元组中。 你喜欢它吗?您会/会使用它吗?是/否,请解释。 问题答案: 对于小型应用程序和所谓的“一次性”脚本,这是可以的,尤其是@ kaizer.se提到的增强功能和@RedGlyph提到的版本。 但是,对于维护寿命长且维护人员众多的大型应用

  • 问题内容: 为什么捕获使用不被视为良好的编程习惯?什么是处理RuntimeException的正确方法? 另外,为什么不赶上?如何执行此行为? 问题答案: 通常,a 表示编程错误(在这种情况下,您无法“处理”该错误,因为如果您知道期望发生错误,则可以避免该错误)。 捕获任何这些常规异常(包括)都是一个坏主意,因为这意味着您声称自己了解所有可能出错的情况,尽管如此,您仍然可以继续。有时(而不是通常)

  • 问题内容: 关于Javadoc的内容不多。(简而言之:它返回字符串的规范表示形式,从而允许使用来比较内部字符串==) 我什么时候可以使用此功能? 是否存在Javadoc中未提及的副作用,即JIT编译器或多或少的优化? 还有其他用途吗? 问题答案: 我何时会使用此函数来支持String.equals() 当你需要速度时,因为可以按引用比较字符串(==比等于快) 是否有Javadoc中未提及的副作用?