Pythonexception的最佳实践?

什么是创buildexception的最佳实践? 我刚刚看到这个,我不知道应该吓到还是喜欢。 我在书中多次阅读,例外永远不会持有一个string,因为string本身可以抛出exception。 任何真实的事实呢?

基本上我从脚本的理解是,这样做是为了让所有的内部Python库有一个常见的错误消息格式(这是迫切需要的东西),所以我可以理解为什么把错误消息string是一个好主意。 (几乎每一个方法都会抛出exception,因为完全不需要无效的通过)。

有问题的代码如下:

""" Base Exception, Error """ class Error(Exception): def __init__(self, message): self.message = message def __str__(self): return "[ERROR] %s\n" % str(self.message) def log(self): ret = "%s" % str(self.message) if(hasattr(self, "reason")): return "".join([ret, "\n==> %s" % str(self.reason)]) return ret class PCSException(Error): def __init__(self, message, reason = None): self.message = message self.reason = reason def __str__(self): ret = "[PCS_ERROR] %s\n" % str(self.message) if(self.reason != None): ret += "[REASON] %s\n" % str(self.reason) return ret 

这只是冰山一angular,但是有人能让我对这个可怕的想法有所了解吗? 或者,如果有更好的exception编码过程/风格。

我在书中多次阅读,例外永远不会持有一个string,因为string本身可以抛出exception。 任何真实的事实呢?

什么?

请提供一个参考或链接到这个。 这完全是不真实的。

由于所有的对象都可以抛出exception,因此该逻辑的exception中不能包含任何对象。

不,“无string”在Python上下文中简直是疯狂的。 也许你在C ++上下文中阅读它。


编辑

曾几何时(在过去的时代),你可以通过名字而不是实际的类来引发一个Pythonexception。

 raise "SomeNameOfAnExceptionClass" 

这不好。 但是这包括一个例外的string。 这是用一个string来命名exception,而不是实际的类对象。 在2.5,这仍然可以工作,但得到一个贬低警告。

也许这就是你读的“不要用string名称引发exception”

强大的exception处理(在Python中) – 我刚才写的一篇“Pythonexception的最佳实践”博客文章。 你可能会觉得它很有用。

博客的一些要点:

切勿使用stream量控制的exception

exception存在于例外情况:不属于正常执行的事件。

如果找不到模式,请考虑对返回-1的string进行“查找”,但超出string末尾的索引会引发exception。 找不到string是正常执行。

在知道如何处理它们的级别处理exception

最好的地方就是可以处理exception的那段代码。 对于一些例外,像编程错误(例如IndexError,TypeError,NameError等等)exception最好留给程序员/用户,因为“处理”它们只会隐藏真正的错误。

总是问“这是处理这个exception的正确的地方吗?” 并注意捕捉所有的例外情况。

logging您的代码抛出的exception

考虑你的代码可能抛出哪些exception将帮助你编写更好,更安全,更封装的代码

我相信反对用string创buildexception的build议来自“Learning Python”(O'Reilly)。 在标题为“ String Exceptions Are Right Out”的章节中, 它指出了(现在已经移除)直接用任意string创buildexception的能力。

它给出的代码是:

 myexc = "My exception string" try: raise myexc except myexc: print ('caught') 

这是在第四版的p858(平装本)。

第一印象是,这是一个例外的代码太多了。

格式化exception应该在logging器configuration中完成。 logging本身也一样。

它还重新定义了标准(和不推荐使用)的消息属性,并且不调用超类的构造函数。 (这可能会或可能不会打破Python 3.0exception链接,我没有尝试,因为我正在运行2.6)

大部分额外的代码可以通过使用BaseException.args来实现,通过将以下内容logging为“消息”:

 '\n==> '.join(exception.args) 

我认为,如果可以使用通用/惯用的机制来完成某些工作,那么在exception处理中尤其应该这样做。 (例外是一种应用程序层间发送信号的机制。)

就我个人而言,我试图避免以外的任何事情

 class SomeException(Exception): pass 

(免责:回答主观,可能是问题的性质。)