DB2存储过程里到底有几种异常处理器啊，怎么区分和用的呢？

根据IBM官方DB2知识中心的文档,DB2存储过程中的异常处理器主要有三种基本类型，另外还有一种特殊的处理方式，它们分别是：CONTINUE（继续）处理器、EXIT（退出）处理器和UNDO（撤销）处理器，以及一种不定义处理器而使用RESIGNAL（重新抛出）的特殊情况，区分和使用它们的关键在于当存储过程执行SQL语句发生错误（也就是异常）时，处理器如何决定存储过程的后续行为：是继续往下执行，还是立刻退出，或者是在退出前做一些清理工作。

第一种，CONTINUE（继续）处理器。 这种处理器最“好说话”，它的工作方式是：当在它的管辖范围内（也就是它所在的BEGIN...END语句块中）发生了指定的异常时，DB2会执行这个处理器里你写的处理代码，比如记录错误日志、给某个变量赋个值等等。关键点在于：执行完这些处理代码后，存储过程不会停止，而是会从发生异常的那条语句的下一条语句开始，继续往下执行，这就好比你在走路时被一块小石头绊了一下，你嘟囔了一句“哎哟”，然后把石头踢到路边，接着继续走你的路，不影响你最终到达目的地，这种处理器适用于那些错误不严重，你可以自己处理掉，并且不希望影响主流程的情况，你尝试删除一个可能不存在的临时表，如果表不存在（会报错），你就在CONTINUE处理器里忽略这个错误，然后继续执行创建这个临时表的语句。

第二种，EXIT（退出）处理器。 这种处理器比较“果断”，当它管辖的范围内发生异常时，DB2同样会先执行处理器里的代码，但不同之处是：执行完处理代码后，存储过程会立即退出当前所在的BEGIN...END语句块，如果这个语句块就是存储过程最外层的块，那么整个存储过程就结束了，如果是在内层的嵌套块里，那么退出后将继续执行外层块中紧接着的语句，这就像你正在执行一个多步骤的任务，其中一个关键步骤失败了，你觉得后续步骤已经没有意义或者肯定会错，于是你决定放弃当前任务，直接离开这个任务环节，EXIT处理器常用于处理那些致命的、无法挽回的错误，一旦发生，整个操作就应该中止。

第三种，UNDO（撤销）处理器。 这是最“严谨”但也相对复杂的一种处理器，它的行为模式和EXIT处理器很像：处理异常后也会退出当前语句块，但它有一个独一无二的特点：在执行处理器里的代码之前，DB2会自动回滚（Rollback） 在当前BEGIN...END语句块内所做的所有数据库更改（比如INSERT、UPDATE、DELETE操作），这就像是数据库事务里的“撤销”操作，设想一下，你在一个事务块里先后更新了A表和B表，但在更新B表时出错了，如果你为这个块定义了UNDO处理器，那么DB2会在触发处理器时，自动把对A表的更新也撤销掉，让数据恢复到执行这个块之前的状态，然后再去执行你写的处理代码（比如记录错误信息），最后退出块，这保证了数据的原子性和一致性，避免出现只更新了A表而B表失败的数据混乱局面，UNDO处理器通常用在需要强事务保证的场景。

除了以上三种明确定义的处理器外，还有一种常见做法是不定义特定的处理器，而是使用RESIGNAL。 这不是一种处理器类型，而是一种处理策略，当存储过程中发生异常，而你又没有为这个异常声明任何CONTINUE、EXIT或UNDO处理器时，这个异常会沿着调用链向上“抛出”，最终会导致存储过程终止，并将错误信息返回给调用者（比如另一个存储过程或应用程序），即使你声明了处理器，在处理器内部你也可以使用RESIGNAL语句，意思是：“我这里虽然捕获了异常，也做了一些记录，但这个错误太严重了我处理不了，现在我把这个错误原样（或稍作修改后）再次抛出去，让我的上级调用者去处理。” 这给了错误处理更大的灵活性。

区分这几种方式就看两点：一是异常发生后程序是否继续执行（CONTINUE会，EXIT和UNDO不会），二是是否自动撤销本语句块内的数据修改（只有UNDO会），在实际编写DB2存储过程时，你需要根据具体业务逻辑对错误的不同容忍度和数据一致性要求，来选择合适的异常处理器或者组合使用它们。