当使用pycharm ide时，如果不使用异常类型，则使用except:会触发来自ide的提示，提示该异常子句是Too broad。

我应该忽略这个建议吗？还是始终特定于异常类型的Python？

几乎总是最好指定一个显式的异常类型。如果使用裸except:子句，最终可能会捕获异常，而不是期望捕获的异常——这可能隐藏错误，或者使程序在不按预期进行调试时更难进行调试。

例如，如果要向数据库中插入一行，可能需要捕获一个异常，该异常指示该行已经存在，因此可以进行更新。

如果指定一个空的except:，还将捕获一个套接字错误，指示数据库服务器已崩溃。最好只捕获您知道如何处理的异常——通常情况下，程序在异常点失败比继续运行要好，但其行为方式却出乎意料。

有一种情况是，您可能希望使用一个裸机except:，它位于您需要始终运行的程序的顶层，就像网络服务器一样。但是接下来，您需要非常小心地记录异常，否则就不可能知道出了什么问题。基本上，在一个这样做的程序中，最多只能有一个地方。

所有这些的一个推论是，您的代码永远不应该执行raise Exception('some message')，因为它强制客户机代码使用except:(或except Exception:)，这几乎同样糟糕。您应该针对要发出信号的问题定义一个异常(可能继承自一些内置的异常子类，如ValueError或TypeError)。或者您应该引发一个特定的内置异常。这使代码的用户能够小心地捕获他们想要处理的异常。

你不应该忽视口译员给你的建议。

从针对python的PEP-8样式指南中：

When catching exceptions, mention specific exceptions whenever
possible instead of using a bare except: clause.

For example, use:

A bare except: clause will catch SystemExit and KeyboardInterrupt exceptions, making it harder to
interrupt a program with Control-C, and can disguise other problems.
If you want to catch all exceptions that signal program errors, use
except Exception: (bare except is equivalent to except
BaseException:).

A good rule of thumb is to limit use of bare 'except' clauses to two
cases:

If the exception handler will be printing out or logging the
traceback; at least the user will be aware that an error has occurred.
If the code needs to do some cleanup work, but then lets the exception
propagate upwards with raise. try...finally can be a better way to
handle this case.

这和Python没什么区别。

例外的关键是尽可能接近问题的起因来处理问题。

因此，您保留的代码可以在特殊情况下触发问题，解决方案"紧挨着"彼此。

问题是，您不能知道一段代码可能抛出的所有异常。您所能知道的就是，如果它是一个假定为"找不到文件"的异常，那么您可以对它进行捕获，并提示用户获取执行该操作的文件，或者取消该函数。

如果你把Try-Catch放在这一点上，那么不管你的文件例程(只读、权限、UAC、不是真正的PDF等)有什么问题，每个人都会进入你的文件中，而你的用户却在尖叫"但是它在那里，这段代码是垃圾"。

现在有两种情况，你可能会抓住一切，但他们应该有意识地选择。

它们是catch，撤消一些本地操作(例如创建或锁定资源(例如打开磁盘上的文件进行写入)，然后再次抛出异常，以便在更高的级别进行处理)。

另一个是你，你不在乎为什么会出错。例如，打印。您可能会遇到一个问题，比如说您的打印机有问题，请将其整理出来，不要因为这个问题而终止应用程序。同样的，如果代码使用某种调度执行一系列单独的任务，你不会希望整个任务都死掉，因为其中一个任务失败了。

注意：如果您执行上述操作，我不能推荐某种异常日志记录，例如，尝试catch log end，这已经足够了。

总是指定异常类型，您不想捕获的类型有很多，如SyntaxError、KeyboardInterrupt、MemoryError等。

你也会用它来抓到例如control-c，所以不要这样做，除非你再次"扔"它。但是，在这种情况下，您应该使用"finally"。

这里是我使用的地方，除了没有类型

这是我的代码中未检查异常的主要用途

我总是添加这个，这样生产代码就不会溢出stacktrace

我有两种方法：

• 第一种方法是：当较高级别的层调用较低级别的函数时，它将调用包装在类型化异常中，以处理"顶级"较低级别的异常。但我添加了一个通用的except语句，以检测低级函数中未处理的低级异常。

我更喜欢这样，我发现更容易检测哪些异常应该被适当捕获：当较低级别的异常被较高级别的异常记录时，我会更好地"看到"问题。

• 第二种方法是：低级层的每个顶级函数都将其代码包装在一个泛型层中，但它捕获该特定层上所有未处理的异常。

一些同事更喜欢这种方式，因为它在较低级别的函数中保留较低级别的异常，它们"属于"这些异常。

试试这个：

我从这个链接得到了答案，如果其他人遇到这个问题，请查看它。