在Python中手动引发(抛出)异常


2261

如何在Python中引发异常,以便以后可以通过except块将其捕获?

Answers:


2934

如何在Python中手动引发/引发异常?

使用在语义上适合您的问题的最特定的Exception构造函数

在您的消息中要具体,例如:

raise ValueError('A very specific bad thing happened.')

不要引发通用异常

避免提出泛型Exception。要捕获它,您必须捕获将其子类化的所有其他更具体的异常。

问题1:隐藏错误

raise Exception('I know Python!') # Don't! If you catch, likely to hide bugs.

例如:

def demo_bad_catch():
    try:
        raise ValueError('Represents a hidden bug, do not catch this')
        raise Exception('This is the exception you expect to handle')
    except Exception as error:
        print('Caught this error: ' + repr(error))

>>> demo_bad_catch()
Caught this error: ValueError('Represents a hidden bug, do not catch this',)

问题2:无法抓住

而且更具体的捕获不会捕获一般异常:

def demo_no_catch():
    try:
        raise Exception('general exceptions not caught by specific handling')
    except ValueError as e:
        print('we will not catch exception: Exception')


>>> demo_no_catch()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in demo_no_catch
Exception: general exceptions not caught by specific handling

最佳做法:raise声明

而是使用在语义上适合您的issue的最特定的Exception构造函数

raise ValueError('A very specific bad thing happened')

这也方便地允许将任意数量的参数传递给构造函数:

raise ValueError('A very specific bad thing happened', 'foo', 'bar', 'baz') 

这些参数由对象args上的属性访问Exception。例如:

try:
    some_code_that_may_raise_our_value_error()
except ValueError as err:
    print(err.args)

版画

('message', 'foo', 'bar', 'baz')    

在Python 2.5中,message添加了一个实际属性,以BaseException鼓励用户继承Exceptions子类并停止使用args,但是args 的引入message和最初的弃用已被收回

最佳做法:except条款

例如,在except子句中时,您可能想要记录发生了特定类型的错误,然后重新引发。保留堆栈跟踪时执行此操作的最佳方法是使用裸机抬高语句。例如:

logger = logging.getLogger(__name__)

try:
    do_something_in_app_that_breaks_easily()
except AppError as error:
    logger.error(error)
    raise                 # just this!
    # raise AppError      # Don't do this, you'll lose the stack trace!

不要修改您的错误...但是如果您坚持的话。

您可以使用来保留stacktrace(和错误值)sys.exc_info(),但这更容易出错,并且在Python 2和3之间存在兼容性问题,建议使用裸机raise重新引发。

解释- sys.exc_info()返回类型,值和回溯。

type, value, traceback = sys.exc_info()

这是Python 2中的语法-请注意,这与Python 3不兼容:

    raise AppError, error, sys.exc_info()[2] # avoid this.
    # Equivalently, as error *is* the second object:
    raise sys.exc_info()[0], sys.exc_info()[1], sys.exc_info()[2]

如果愿意,您可以修改新加薪后的情况-例如args,为实例设置新值:

def error():
    raise ValueError('oops!')

def catch_error_modify_message():
    try:
        error()
    except ValueError:
        error_type, error_instance, traceback = sys.exc_info()
        error_instance.args = (error_instance.args[0] + ' <modification>',)
        raise error_type, error_instance, traceback

并且我们在修改args时保留了整个回溯。请注意,这不是最佳做法,并且在Python 3中是无效的语法(使得保持兼容性变得更加困难)。

>>> catch_error_modify_message()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in catch_error_modify_message
  File "<stdin>", line 2, in error
ValueError: oops! <modification>

Python 3中

    raise error.with_traceback(sys.exc_info()[2])

同样:避免手动操作回溯。它效率较低,更容易出错。而且,如果您正在使用线程,sys.exc_info甚至可能会得到错误的回溯(特别是如果您对控制流使用异常处理,我个人倾向于避免这种情况。)

Python 3,异常链接

在Python 3中,您可以链接异常,以保留回溯:

    raise RuntimeError('specific message') from error

意识到:

  • 确实允许更改引发的错误类型,并且
  • 这与Python 2 兼容。

不推荐使用的方法:

这些可以轻松隐藏甚至进入生产代码。您想提出一个例外,而这样做会引发一个例外,但不是一个预期的例外

在Python 2中有效,但在Python 3中无效

raise ValueError, 'message' # Don't do this, it's deprecated!

在更旧的Python版本(2.4及更低版本)中有效,您仍然可以看到有人在引发字符串:

raise 'message' # really really wrong. don't do this.

在所有现代版本中,这实际上会引发一个TypeError,因为您没有引发一个BaseException类型。如果您没有检查正确的例外情况,并且没有知道此问题的审阅者,那么它可能会投入生产。

用法示例

我提出异常以警告使用者如果我的API使用不正确:

def api_func(foo):
    '''foo should be either 'baz' or 'bar'. returns something very useful.'''
    if foo not in _ALLOWED_ARGS:
        raise ValueError('{foo} wrong, use "baz" or "bar"'.format(foo=repr(foo)))

适当时创建自己的错误类型

“我想故意犯一个错误,以便将其排除在外”

您可以创建自己的错误类型,如果要指示应用程序存在某些特定的错误,只需在异常层次结构中将适当的点子类化:

class MyAppLookupError(LookupError):
    '''raise this when there's a lookup error for my app'''

和用法:

if important_key not in resource_dict and not ok_to_be_missing:
    raise MyAppLookupError('resource is missing, and that is not ok.')

19
谢谢,这正是我所需要的。裸露的raise是我需要能够在代码执行的多个级别上执行自定义错误调试而不破坏堆栈跟踪的东西。
CaffeineConnoisseur

这是一个很好的答案。但是我仍然使用大量的2.7代码,并且我经常发现自己想要向意外的异常添加信息,例如输入文件位置或某些变量的值,但要保留原始堆栈和异常。我可以记录它,但是有时我不希望它记录下来,例如,如果父代码最终处理了它。raise sys.exc_info()[0], (sys.exc_info()[1], my_extra_info), sys.exc_info()[2]似乎可以满足我的要求,而且我从未遇到过麻烦。但这感觉很骇人,不是公认的做法。有没有更好的办法?
Michael Scheper

2
@brennanyoung在这种情况下,我认为引发SyntaxError可能会令人困惑-可能应该引发自定义异常。我在这里解释了如何操作:stackoverflow.com/a/26938914/541136
亚伦·霍尔

2
请注意,完整的引号是“所有内置的,非系统退出的异常都派生自此类。所有用户定义的异常也应派生自此类。” -这主要意味着您不应该使用不是从其派生的4个异常之一Exception作为父类-您可以对更具体的东西进行子类化,并且在有意义的情况下应该这样做。
亚伦·霍尔

1
在“ 最佳做法:except子句 ” 的示例中,您使用未定义的AppError异常。最好使用内置错误,例如AttributeError
Stevoisiak,

530

不要这样做。赤身裸体Exception绝对不是正确的选择。请参阅亚伦·霍尔(Aaron Hall)的出色答案

不能得到比这更多的pythonic:

raise Exception("I know python!")

如果您需要更多信息,请参阅python 的凸起语句文档


67
不谢谢!这消除了具体捕捉您所捕获内容的可能性。这是完全错误的方法。让我们来看看亚伦·霍尔(Aaron Hall)的出色答案,而不是这个答案。我希望现在每个答案能给我一个以上的赞成票。
达伍德·伊本·卡里姆

27
@PeterR如此之少的投票数也同样令人恐惧。任何人都想读这个答案,那就不要做这个!正确的答案是亚伦·霍尔的答案。
达伍德·伊本·卡里姆

6
我认为应该对为什么这是错误的或如此糟糕的问题进行更详细的解释。
查理·帕克

9
@CharlieParker有。这是亚伦·霍尔回答的第一部分。
Dinei

5
为什么不能将此答案标记为删除?它已经有93个投票!
codeforester

54

在Python3中,有四种用于引发异常的语法:

1. raise exception 
2. raise exception (args) 
3. raise
4. raise exception (args) from original_exception

1.引发异常vs. 2.引发异常(参数)

如果raise exception (args) 用于引发异常,则在 args打印异常对象时将打印出-如下例所示。

  #raise exception (args)
    try:
        raise ValueError("I have raised an Exception")
    except ValueError as exp:
        print ("Error", exp)     # Output -> Error I have raised an Exception 



  #raise execption 
    try:
        raise ValueError
    except ValueError as exp:
        print ("Error", exp)     # Output -> Error 

3.提高

raise不带任何参数的语句重新引发最后一个异常。如果您需要在捕获异常后执行一些操作然后重新引发它,这将很有用。但是,如果以前没有异常,则raise语句引发 TypeErrorException。

def somefunction():
    print("some cleaning")

a=10
b=0 
result=None

try:
    result=a/b
    print(result)

except Exception:            #Output ->
    somefunction()           #some cleaning
    raise                    #Traceback (most recent call last):
                             #File "python", line 8, in <module>
                             #ZeroDivisionError: division by zero

4.从original_exception引发异常(参数)

该语句用于创建异常链接,其中响应另一个异常而引发的异常可以包含原始异常的详细信息-如下例所示。

class MyCustomException(Exception):
pass

a=10
b=0 
reuslt=None
try:
    try:
        result=a/b

    except ZeroDivisionError as exp:
        print("ZeroDivisionError -- ",exp)
        raise MyCustomException("Zero Division ") from exp

except MyCustomException as exp:
        print("MyException",exp)
        print(exp.__cause__)

输出:

ZeroDivisionError --  division by zero
MyException Zero Division 
division by zero

7
请注意,PEP8 exception(args)胜过exception (args)
Gloweye

raise exception(args) from None可以说已经处理了当前活动的异常,不再引起关注。否则,如果您在一个except块内引发一个异常并且未对其进行处理,则将通过消息“处理上述异常期间,发生另一个异常”来分隔显示两个异常的回溯
cg909

35

对于常见的情况,您需要针对某些意外情况抛出异常,并且您从不打算抓住它,而只是快速失败以使您能够从那里进行调试(如果发生的话)—最合乎逻辑的是AssertionError

if 0 < distance <= RADIUS:
    #Do something.
elif RADIUS < distance:
    #Do something.
else:
    raise AssertionError("Unexpected value of 'distance'!", distance)

19
ValueErrorAssertionError因为断言没有问题(因为这里没有做任何事情)而存在问题更好-因为问题在于值。如果您确实需要AssertionError在这种情况下,请编写assert distance > 0, 'Distance must be positive'。但是您不应该以这种方式进行错误检查,因为可以关闭断言(python -O)。
两位炼金术士

1
@ Two-BitAlchemist好点。当我编写上面的简单示例时,这种想法被简化了。在许多类似情况下,这是与特定值无关的条件。相反,其含义是“控制流永远不会到达这里”。
Evgeni Sergeev

2
可以关闭@ Two-BitAlchemist断言,是的,但是您根本不应该使用它们来进行错误检查吗?
Evgeni Sergeev

这要看情况。我不会让它成为我打算分发的程序中唯一的错误检查。另一方面,我可以只为我的同事编写一个程序,并告诉他们如果使用来运行该程序,后果自负-O
两位炼金术士

1
@ Two-BitAlchemist对我来说,断言的作用不是本身的错误检查(这是测试的目的),但是它们在代码中设置了某些漏洞无法通过的篱笆。因此,更容易查找和隔离错误,而这些错误将不可避免地发生。这只是良好的习惯,几乎不需要付出任何努力,而测试则需要付出很多努力和大量时间。
Evgeni Sergeev 2015年

12

首先阅读现有的答案,这只是一个附录。

请注意,可以带或不带参数引发异常。

例:

raise SystemExit

退出程序,但是您可能想知道发生了什么。因此可以使用它。

raise SystemExit("program exited")

这将在关闭程序之前将“程序退出”打印到stderr。


2
这不是违背OOP范式吗?我假设,第一种情况引发类引用,第二种情况引发SystemExit实例。会不会raise SystemExit()是更好的选择?为什么第一个甚至可以工作?
燃烧

2

抛出异常的另一种方法是assert。您可以使用assert来验证是否满足条件,否则条件将上升AssertionError。有关更多详细信息,请在此处查看

def avg(marks):
    assert len(marks) != 0,"List is empty."
    return sum(marks)/len(marks)

mark2 = [55,88,78,90,79]
print("Average of mark2:",avg(mark2))

mark1 = []
print("Average of mark1:",avg(mark1))

2

只是要注意:有时候您确实想处理通用异常。如果要处理大量文件并记录错误,则可能要捕获文件发生的任何错误,将其记录下来,然后继续处理其余文件。在这种情况下,

try:
    foo() 
except Exception as e:
    print(str(e)) # Print out handled error

阻止这样做的好方法。您仍然需要raise特定的异常,以便您了解异常的含义。


0

您应该为此学习python的凸起语句。它应该保存在try块中。范例-

try:
    raise TypeError            #remove TypeError by any other error if you want
except TypeError:
    print('TypeError raised')
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.