{IO}代码数据库连接代码catch（ioe）处理IO

第1点：尽量使用try...catch...语句来处理异常，并尽可能回收内存资源。

第2点，尽量减少try监控的代码块。

例如，一个方法有100行，其中第4到20行代码用于连接数据库，第50到90行代码用于连接网络。 我见过很多程序员直接围住它，图省事。 第4行到第90行的代码也围绕着一些不需要用try监控的代码。

4 尝试{

……

10 连接到数据库...

第21行到49行是不需要监控的代码块

50

...连接到网络的代码

90}

91 捕获（e）…

这样做的后果是，一旦第10行发生数据库异常，就会直接跳转到第91行的异常处理代码，这样不应该受影响的代码（比如第21行到第90行）就不会被执行。 。

对此，我们应该在代码中使用多个try...catch...来包围应该监控的代码。 不需要监控的代码绝对不应该受到try的影响。

第三点：先用专业的异常来处理，最后再用异常来搞清楚事情的真相。

如果我们在try代码块中进行IO和数据库操作，那么我们首先要使用专业的sum来处理相关的异常，最后再使用。 代码如下。

尝试{

IO代码

数据库连接代码

catch(ioe){处理IO异常的代码}

catch(ioe){处理数据库操作异常的代码},

catch(ioe){最后使用这个异常基类}

不过我见过很多程序员为了省事也直接用它。

尝试{

IO代码

数据库连接代码

catch(ioe){最后使用这个异常基类}

我们知道它是所有异常处理类的父类。 直接使用没有语法问题。 但是，如果我们不使用专业的异常处理类，我们就无法知道异常的具体信息。

例如，在操作数据库时，我们可能会遇到数据库故障、表字段不匹配等不同类型的异常。 如果我们在没有专业知识的情况下简单地使用，我们只能知道发生了异常，但无法深入了解异常的具体信息。 这使得无法更好地处理异常。

第4点：在catch子句中，不要简单地抛出异常，并尽可能地处理异常。

例如，在下面的catch子句中，除了抛出异常信息之外，它什么也不做。 这不是一个好方法。 推荐的方法是，例如，弹出一个对话框，告诉用户发生了什么以及下一步该做什么。

捕获（前）{ 前。（）; }

再比如，如果我们使用catch语句捕获了数据库连接异常，那么我们可以尝试连接备份数据库，也可以等待10秒再尝试连接。 总之，异常发生后，应尽力保证业务流程能够正常进行。 如果不能保证，就应该以友好的方式告诉用户当前的情况（而不是使用只有程序员才能理解的技术语言），以便让用户知道下一步该做什么。

第五点：异常发生后，尽量保证项目不会被终止，并尽量将异常的影响降到最低。

例如，如果有两个并行的业务，即使其中一个业务出现异常，另一个业务也应该继续执行。 如果我们错误地将业务1和业务2都包含在一个try子句中，那么一旦业务1发生异常，就会跳转到catch处理流程，从而导致业务2无法执行，这就违背了最初的设计意图。

//写错了

尝试{

商务1

商务2

catch(e){处理异常的代码}

为此，我们应该使用两个 try...catch... 块，分别包含业务 1 和业务 2。 代码如下。

尝试{

商务1

catch(e){处理异常的代码}

尝试{

商务2

catch(e){处理异常的代码}

让我们再看一个例子。 比如我们要从一个csv文件中读取100条数据，然后将它们依次插入到数据库中。 如果其中一条插入语句出错，不会影响其他插入操作。 我们来看一下错误的书写方式。

//写错了

尝试{

for(int i=0;i

{读取其中一条数据并将其插入数据库}

catch(e){处理数据库操作异常的代码}

在上面的写法中，如果插入第10条数据时出现异常，会立即跳转到catch子句的异常处理代码，从而导致接下来的第11条到第100条数据无法插入。

正确的写法是，我们将每个插入动作都用try...catch...语句包围起来，这样本次插入失败就不会影响后续的插入动作，从而将影响降到最低。

for(int i=0;i

尝试{

读取一条数据并插入数据库

捕获（e）{

处理数据库操作异常的代码

;