C#中的backgroundWorker的DoWork出错时，如何让调试器断在出错点？

Question

本帖最后由 sunbinjin 于 2014-12-04 19:34:39 编辑

Answer 1

RunWorkerCompleted事件e.Error就是异常信息，你根据e.Error.Message进行分析不行么？

Answer 2

不行啊，这个肯定想过，复杂的现场重现，才以知道哪些地方出问题了
这点上我感觉ms应该在backgroundWorker做个开关，允许捕获异常或关闭，结果它做死了，这个类在开发时基本不能用……
逼着开发时用别的多线程方式，发布时改代码到backgroundWorker？明显不符合开发规范

Answer 3

这是开发方法论的问题，不是单纯的调试问题。开发时，你的目标应该仅仅是“眼前”，比如说1~3个小时的工作。我想你的情况更应该缩短这个时间，你每隔30分钟所开发的程序，就应该单独设计为一个单元。你应该为这些眼前的目标单元书写测试用例，然后让它们通过。前一个单元没有通过，根本没有必要去开始考虑开发下一个单元。因此一个方法即使是在 BackgroundWorker 运行，它都应该首先不在 BackgroundWoker 内被测试几十次了，你才让它将来（可能是2天以后）在下一步backgroundWorker中运行。

Answer 4

开发的“规范”不是教条，是行动。而行动方法是 know-how，一般来说没有经验的人都很难理解 know-how，没有经验的人往往喜欢死记硬背规范，而不会运用规范。

Answer 5

如果你不能保证每一个函数,每一个类都能够正常的工作,就把他们胡乱拼凑在一起,然后想要整个程序联调的时候才去解决那些隐藏的bug,是不靠谱的做法

Answer 6

开发的“规范”不是教条，是行动。而行动方法是 know-how，一般来说没有经验的人都很难理解 know-how，没有经验的人往往喜欢死记硬背规范，而不会运用规范。晕，你说这些有啥用呢？难道这所有人写的代码都没bug？都是写完了就能达到release级别？
我觉得你过于教条了，脱离实际了

Answer 7

现场好的代码，都需要debug，你这点不能否认
既然需要debug，backgroundWorker确又阻碍了debug，这就是生产环节上出问题了
按你们这么说，Thread类里也不能让你debug了，一切都不让你debug了，你受得了？能debug时最好是可以debug
我是debug版，需要debug，这就是意义

Answer 8

我觉得你陷入了一个误区,认为好的代码需要DEBUG,所以任何代码都应该在真正运行起来的时候能够DEBUG
其实代码不分好坏,都必须通过测试,通不过测试的代码已经不能以好坏来形容了,根本就是不能用的废品而你想所有代码都可以通过断点调试的形式去debug,这也是不现实的
多线程的应用中,很多时候抛异常并不是因为某个单独的代码引起的,而是多线程本身引发的异常,即使你跟踪到出错的代码,也不是说单纯改掉这里就没有异常了,这需要你有全局的把握和分析能力而且多线程中也根本没办法断点一步一步调试

Answer 9

这个与代码好坏无关啊，这是功能需求
按你这么说，Thread与backgroundWorker相近，c#的Thread起的线程，也不让你debug了，如何？
我郁闷的是：明明直接给我debug就得了，为啥不给？没必要啊

Answer 10

多线程的代码可以debug啊，打个断点就行了，但是调试时会在主线程和这个分开来的任务里来回跳，比较麻烦，需要你自己探索调试技巧

Answer 11

没什么办法
backgroundWorker封装的时候就已经自己加了try,catch,出错就抛异常了,而不会停在出错位置