Python 类型提示与异常
我有一个如下所示的函数:
def check_for_errors(result):
if 'success' in result:
return True
if 'error' in result:
raise TypeError
return False
在成功运行此函数时,我应该得到一个 bool
,但如果出现错误,我应该得到一个 TypeError
- 这是好的,因为我在另一个函数中处理它。
我的函数第一行如下所示:
def check_for_errors(result: str) -> bool:
我的问题是:我应该在类型提示中提及错误吗?
I have a function that looks like this:
def check_for_errors(result):
if 'success' in result:
return True
if 'error' in result:
raise TypeError
return False
In successful run of this function, I should get a bool
, but if there is an error I should get a TypeError
- which is OK because I deal with it in another function.
My function first line looks like this:
def check_for_errors(result: str) -> bool:
My question is: Should I mention the error in my type hinting?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
类型提示不能说明任何有关异常的信息。它们完全超出了该功能的范围。但是,您仍然可以在文档字符串中记录异常。
来自 PEP 484 -- 类型提示 :
Guido van Rossum 强烈反对在类型提示规范中添加例外,因为他不希望最终陷入需要检查异常(在调用代码中处理)或在每个级别显式声明的情况。
Type hinting can't say anything about exceptions. They are entirely out of scope for the feature. You can still document the exception in the docstring however.
From PEP 484 -- Type Hints:
Guido van Rossum has strongly opposed adding exceptions to the type hinting spec, as he doesn't want to end up in a situation where exceptions need to be checked (handled in calling code) or declared explicitly at each level.
将异常路径作为函数类型注释的一部分是有充分理由的,至少在某些情况下是这样。它只是在您需要了解调用者必须处理哪些异常时,从类型检查器中为您提供更多帮助。 (如果您有兴趣进行更深入的分析,我写了 一篇关于此的博客文章。)
由于指示函数引发哪些异常超出了 Python 类型系统的范围(例如,在 Java 中),我们需要一个解决方法来获得 这。我们可以
返回
异常,而不是引发异常。这样,异常就成为函数签名的一部分,调用者必须利用类型检查器的强大功能来处理它。以下代码的灵感来自Rust 中完成异常处理的方式< /a>:它提供一个
Result
类型,可以是Ok
或Err
。Ok
和Err
类都有一个unwrap()
函数,该函数返回包装的值或引发包装的异常。Result
是一个Generic
,它有两种类型:Ok
值的类型和Err
值的类型代码 > 异常。这里将其应用于您的示例:这只是一个粗略的代码草图,用于演示原理。实际上有一个更复杂的库,poltergeist,如果您考虑遵循这种方法,我建议您使用它。
There are good reasons for making the exception path part of the type annotations of your function, at least in certain scenarios. It just provides you more help from the type checker whenever you need to understand which exceptions the caller has to handle. (If you are interested in a more in-depth analysis, I wrote a blog post about this.)
As it is out of scope of the Python typing system to indicate which exceptions a function raises (like, for instance, in Java), we need a workaround to get this. Instead of raising, we can
return
the exception. That way, the exception becomes part of the function signature, and the caller has to handle it, leveraging the power of the type checker.The following code is inspired by the way exception handling is done in Rust: It provides a
Result
type which can either beOk
orErr
. BothOk
andErr
classes have anunwrap()
function, which either returns the wrapped value or raises the wrapped exception.Result
is aGeneric
, and it takes two types: the type of theOk
value, and the type of theErr
exception. Here it is applied to your example:This is just a rough code sketch to demonstrate the principle. There is actually a more sophisticated library, poltergeist which I would recommend to use, if you consider following this approach.
记录错误通常是个好主意。这意味着使用您的函数的其他开发人员将能够处理您的错误,而无需阅读您的代码。
It is usually a good idea to document the error. This means that another developer using your function will be able to handle your errors without having to read through your code.
您可以使用NoReturn:
https://peps.python.org/pep-0484/#the- noreturn-type
或者这样:
You can use NoReturn:
https://peps.python.org/pep-0484/#the-noreturn-type
Or this: