本文探讨了在C++扩展与VisualBasic中，过滤器表达式与finally声明的执行顺序对安全的影响。过滤器通常先于finally块执行，可能引发安全问题。文章提供了修正示例，展示了如何通过调整异常处理逻辑来解决此类问题。
在被管理的 C++ 扩展与 Visual Basic 中，过滤器表达式能够更进一步地让堆栈运行在任何 finally 声明之前。而与过滤器相关联的 catch 块则运行在 finally 声明之后。关于更多信息，请参考：［使用被用户过滤的异常］。本文只对这个次序的安全含义进行审查。考虑下列说明了在过滤器声明与 finally 声明中的运行次序的伪代码范例。
这个代码将显示下列内容。
Throw Filter Finally Catch
过滤器运行在 finally 声明之前，因此安全问题能够通过在其他代码的执行能够获取优势的时候所产生状态变化的任何事物而被引入。例如：
这个伪代码允许过滤器提升堆栈的地位来运行任何代码。其他具有类似作用的操作范例则会临时扮演另外的身份，设置一个迂回的内部安全检查标记，或者改变与线程相关联的文化。建议的解决方案就是引入一个异常处理器对调用者的过滤器声明块中的代码对于线程状态的改变进行隔离。但是，这个问题在异常处理器适当地被引入或者在问题无法被修复的时候仍然是重要的。虽然下列范例切换了 UI 文化，但是任何种类的线程状态变化同样能够是被暴露的。
这种情况下的正确修复就是在一个 try/catch 块中包装现有的 try/finally 块。然而，只是简单地引入一个 catch-throw 子句到现有的 try/finally 块中并不会修复这个问题，如下列范例所示。
这样做根本就不会修复问题，因为 finally 声明并没有运行在 FilterFunc 获取到控件之前。
下列范例通过确保 finally 子句在为调用者的异常过滤器块而提供一个异常之前能够被执行的方式来修复了这个问题。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
