为了让程序顺利地运行，我们会在工程的无数地方埋雷：
TRY...CATCH...FINALLY
on error do something
这些错误处理程序，若当初考虑不周，本身就存在缺陷或有逻辑错误，可能会将软件的调试带入深沟里去！——我们可能会无法发现某些隐藏比较深的错误，因为它们被错误处理程序给悄悄屏蔽并无意中忽略掉了。
有时候，调试到忍无可忍时，我们会无限渴望：
能否“一键屏蔽”工程内自己添加的全部错误处理程序，好让任何错误都无所遁形，直接暴露出来？
等最终调试完毕，又“一键恢复”全部错误处理程序，好让不必要的错误与最终用户隔离。
——这个……有辙不？

#define

我说的是“亡羊补牢”，而非“未雨绸缪”啊。
若重头开始写一个新工程，当然可以到处加#define；
主要是当下的烂摊子：
on error业已遍地开花了，如何收拾残局，一键迅速找出错误，然后再一键恢复错误处理程序。
是这么一个意思，主要是。

既然用了 TRY...，on error...，应该有抛出异常时的处理过程吧

运行结果不正确，反复调试无解。
最终怀疑可能是异常处理过程本身就存在逻辑错误。
想要查找“问题解决代码的问题”，这就相对困难了。
必须将所有的原始错误，直接暴露出来，否则查起错误处理程序来茫无头绪，查无可查。

自己开发的，在那个地方，做了什么，都清楚的，怎么还会不知道故障在哪里呢
除非不是自己开发的，维护别人的

ON ERROR，只是为了系统在报错误的时候，还能正常退出，运行，等操作

假如是自己3年前、5年前、甚至10多年前开发的工程呢？年纪大啦，哪有那么好的记性啊！

看几位大佬都这么说，估计没有捷径。要不这么着，自己模仿Unfoxall附送的几个开源小工具，改写一个“解决绝世难题小工具”吧：
一键屏蔽全部异常处理代码.prg
一键恢复全部异常处理代码.prg
无非就是遍历全部prg、vcx、scx等等，搜出异常处理代码，然后【多行注释/多行撤销注释】，难倒是不难，就是得小心点儿。呵呵。

能否“一键屏蔽”工程内自己添加的全部错误处理程序，好让任何错误都无所遁形，直接暴露出来？
等最终调试完毕，又“一键恢复”全部错误处理程序，

想实现上边的效果 也可以：

每一个错误处理语句段 保存在一个相同的条件语句中 当条件为  t  则执行  
通过修改条件 即可 完成 一键屏蔽 或 一键恢复

[此贴子已经被作者于2022-6-14 16:35编辑过]