我没有读过太多关于它的内容,但是下面链接的作者建议我不要使用"冒泡"来集中VBA中的错误处理.
但我不确定他为什么这么推荐,而且他没有真正解释.
有人能告诉我为什么我应该在每个程序中使用错误处理而不是使用"冒泡"吗？或者至少,你知道为什么作者说不？
谢谢.
jto*_*lle 13
对您的第一个问题的简短回答是"您不应该在每个过程中放置错误处理程序".
要说"每个程序必须有一个错误处理程序"一般都是可怕的建议.其他地方已经讨论了VBA错误处理的缺陷.但从概念上讲,它与其他语言中更标准的异常处理形式并没有什么不同.这些语言的大多数最佳实践都适用.您应该在处理它们的最低级别处理错误.有时这是在发生错误的过程中,很多时候没有.
例如,从工作表调用的VBA UDF当然应该有一个EH,确保将Excel错误值返回给调用单元,而不是将用户放入代码编辑器中并显示错误消息.但是,从UDF调用的代码可能需要也可能不需要.事实上,当发生错误时,内部例程通常可以做的最有意义的事情就是让它传递到堆栈上,以便它可以访问知道如何处理它的代码.这真的取决于例程.
第二个问题的答案是作者似乎不太了解异常处理.他承认错误处理是特定于上下文的,但似乎建议每个过程都应在本地"在此纠正问题并恢复执行"和"终止程序"之间做出决定.他遗漏了通常正确的选项,即"在当地清理并将问题解决到楼上".因此,无需在本地清理的例程应该让错误"冒泡".
我不确定 VBA 的默认错误处理是什么，但由于它是 Visual Basic for Applications，并且这些应用程序包括 Excel 和 Word 等内容，我假设只会出现一个对话框，这对用户没有帮助。
我认为作者已经被不处理错误的代码所困扰，所以他现在推荐所有处理错误的过程。
完整的答案是，您必须了解可能发生的每个错误，并有适当的代码来处理它，无论它是尽可能低（您可能不知道该怎么做），还是尽可能高（这意味着编写错误处理代码的工作量更少，但不知道错误发生的原因），或者策略性地（正好在正确的位置，您应该能够从最常见的错误中恢复）或者到处（这可能太多了）开发工作）。