如何检查线程代码是否在 try-catch 块中运行
我想验证我们的代码并检查我们执行的每个线程是否在 try catch 块中运行。
有效样本:
Thread loadDataThread = new Thread(new ThreadStart(LoadData));
public void LoadData()
{
try {/*do something*/}
catch(Exception ex) { /*Handle exception*/ }
}
无效样本:
Thread loadDataThread = new Thread(new ThreadStart(LoadData));
public void LoadData()
{
/* do something */
}
是否可以使用 FxCop 或其他工具进行验证。类似的规则可以应用于其他一些事情,例如。计时器滴答声等...
I would like to validate our code and check if every Thread that we execute runs in try catch block.
A valid sample:
Thread loadDataThread = new Thread(new ThreadStart(LoadData));
public void LoadData()
{
try {/*do something*/}
catch(Exception ex) { /*Handle exception*/ }
}
Not valid sample:
Thread loadDataThread = new Thread(new ThreadStart(LoadData));
public void LoadData()
{
/* do something */
}
Is this something that could be verified with FxCop or some other tool. The similar rule could be applied for some other things eg. Timer Ticks etc...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
此是滚动您自己的 FxCop 规则的非常好的资源。通过谷歌搜索,您可能会找到许多其他相同的内容。
我相信您可以开始查看 Thread 构造函数的调用者。然后在调用语句中,您可以通过查看委托参数来获取线程过程的地址。获得方法引用后,您需要检查方法体内的语句以获取所需的结构。
This is a very good resource for rolling your own FxCop rule. You may find many other by googling for the same.
I believe that you can start looking at callers for Thread constructor. Then in calling statement, you can get address of thread procedure by looking at the delegate parameter. Once method ref is obtained, you need inspect statements within method body for the structure you are hoping for.
这不会直接回答您的问题,但可能是相关的。
您是否有兴趣执行上述操作,因为您不希望应用程序在线程抛出未捕获的异常时退出/崩溃?如果是,那么您可以将以下内容添加到 app.config 文件的配置部分:
免责声明 不建议执行上述操作,但可以在万不得已的情况下使用。
警告:如果您决定使用上述内容,您的应用程序将不会报告任何错误并继续尽力执行。因此,您应该有一个处理程序,至少可以通过以下方式记录任何未捕获的异常
this does not answer your question directly but is probably pertinent.
Are you interested in doing the above because you do not want your application to exit/crash when a thread throws an uncaught Exception? If yes, then you can add the following to your app.config file in the configuration section:
disclaimer Doing the above is not recommended but may be used in a situation of last resort.
Warning: If you decide to use the above your application will not report any errors and go on executing as best it can. As a result you should have a handler that will at least log any uncaught exceptions via
请参阅 http://social .msdn.microsoft.com/Forums/en-US/vstscode/thread/a257a910-126e-4c8d-aab3-3199347346ec 有关如何检测 FxCop 规则中的包装 try/catch 块的示例。实际上比较棘手的是检测哪些方法容易从后台线程运行,因为它们并不是全部使用 Thread.Start 或 ThreadPool.QueueUserWorkItem 等明显的启动器生成。
也就是说,您可能需要重新考虑将方法从添加包装 try/catch 转换为使用为您添加 try/catch 的自定义线程启动器。 (然后您可以创建一个 FxCop 规则来验证是否正在使用自定义启动器/帮助器而不是基本框架类似物。)这将具有允许您系统地将其他更改应用于所有线程的优点(例如:设置区域性、跟踪启动堆栈跟踪以用于以后的异常日志记录等),而无需更改从生成的线程运行的所有方法。
See http://social.msdn.microsoft.com/Forums/en-US/vstscode/thread/a257a910-126e-4c8d-aab3-3199347346ec for an example of how to detect a wrapping try/catch block in an FxCop rule. What's actually quite a bit trickier to do is detect which methods are susceptible to being run from a background thread since they're not all spawned using obvious launchers like Thread.Start or ThreadPool.QueueUserWorkItem.
That said, you might want to reconsider switching your approach from adding wrapping try/catches to using custom thread launchers that add the try/catch for you. (You could then create an FxCop rule to verify that the custom launchers/helpers are being used instead of the base framework analogs.) This would have the advantage of allowing you to systematically apply other changes to all thread (e.g.: setting cultures, tracking launching stack trace for use in later exception logging, etc.) without needing to change all the methods run from spawned threads.
我不知道您是否可以在 FXCop 中为此添加自定义规则,但您可以使用
Mono.Cecil
来执行此操作,但它并不那么简单。I do not know if you can add a custom rule for this in FXCop, but you could use
Mono.Cecil
to do this, but it is not that simple.