问题描述
我写的backgroundWorker的DoWork中代码量非常大，功能非常复杂，而且在开发阶段，极有可能会出错的以前用界面线程直接调用时没事，只是会卡死界面，但出错时会正常断在错误处，以便宜我调试，分析，解BUG现在用backgroundWorker后，出错直接就报个Complet就完了，我想分析啊，怎么办？我要调用堆栈，我要量变监控，才能解bug，这样软件怎么才能完善所以，求backgroundWorker线程中直接能出错时断下来的方法，呈现完整的可Debug的状态，放弃backgroundWorker或try或用thread这种都不是我想要的哦，我只想用backgroundWorker且要debug，项目原因复杂，无法一下解释清楚：）
解决方案
本帖最后由 sunbinjin 于 2014-12-04 19:34:39 编辑
解决方案二：
RunWorkerCompleted事件e.Error就是异常信息，你根据e.Error.Message进行分析不行么？
解决方案三：
引用1楼lovelj2012的回复:
RunWorkerCompleted事件e.Error就是异常信息，你根据e.Error.Message进行分析不行么？
不行啊，这个肯定想过，复杂的现场重现，才以知道哪些地方出问题了这点上我感觉ms应该在backgroundWorker做个开关，允许捕获异常或关闭，结果它做死了，这个类在开发时基本不能用……逼着开发时用别的多线程方式，发布时改代码到backgroundWorker？明显不符合开发规范
解决方案四：
这是开发方法论的问题，不是单纯的调试问题。开发时，你的目标应该仅仅是“眼前”，比如说1~3个小时的工作。我想你的情况更应该缩短这个时间，你每隔30分钟所开发的程序，就应该单独设计为一个单元。你应该为这些眼前的目标单元书写测试用例，然后让它们通过。前一个单元没有通过，根本没有必要去开始考虑开发下一个单元。因此一个方法即使是在BackgroundWorker运行，它都应该首先不在BackgroundWoker内被测试几十次了，你才让它将来（可能是2天以后）在下一步backgroundWorker中运行。
解决方案五：
引用2楼sunbinjin的回复:
逼着开发时用别的多线程方式，发布时改代码到backgroundWorker？明显不符合开发规范
开发的“规范”不是教条，是行动。而行动方法是know-how，一般来说没有经验的人都很难理解know-how，没有经验的人往往喜欢死记硬背规范，而不会运用规范。
解决方案六：
如果你不能保证每一个函数,每一个类都能够正常的工作,就把他们胡乱拼凑在一起,然后想要整个程序联调的时候才去解决那些隐藏的bug,是不靠谱的做法
解决方案七：
引用4楼sp1234的回复:
Quote: 引用2楼sunbinjin的回复:
逼着开发时用别的多线程方式，发布时改代码到backgroundWorker？明显不符合开发规范开发的“规范”不是教条，是行动。而行动方法是know-how，一般来说没有经验的人都很难理解know-how，没有经验的人往往喜欢死记硬背规范，而不会运用规范。
晕，你说这些有啥用呢？难道这所有人写的代码都没bug？都是写完了就能达到release级别？我觉得你过于教条了，脱离实际了
解决方案八：
引用5楼Z65443344的回复:
如果你不能保证每一个函数,每一个类都能够正常的工作,就把他们胡乱拼凑在一起,然后想要整个程序联调的时候才去解决那些隐藏的bug,是不靠谱的做法
现场好的代码，都需要debug，你这点不能否认既然需要debug，backgroundWorker确又阻碍了debug，这就是生产环节上出问题了按你们这么说，Thread类里也不能让你debug了，一切都不让你debug了，你受得了？能debug时最好是可以debug我是debug版，需要debug，这就是意义
解决方案九：
代码量大就分成功能模块，从面向对象的角度就是放各个功能放到各种类里，复杂的选项或者配置也用类来描述每个类负责自己的功能以及异常处理在整个功能的调用（子线程）中捕获未处理的异常，出错的时候相信你不会再这么迷茫了
解决方案十：
我觉得你陷入了一个误区,认为好的代码需要DEBUG,所以任何代码都应该在真正运行起来的时候能够DEBUG其实代码不分好坏,都必须通过测试,通不过测试的代码已经不能以好坏来形容了,根本就是不能用的废品而你想所有代码都可以通过断点调试的形式去debug,这也是不现实的多线程的应用中,很多时候抛异常并不是因为某个单独的代码引起的,而是多线程本身引发的异常,即使你跟踪到出错的代码,也不是说单纯改掉这里就没有异常了,这需要你有全局的把握和分析能力而且多线程中也根本没办法断点一步一步调试
解决方案十一：
引用9楼Z65443344的回复:
我觉得你陷入了一个误区,认为好的代码需要DEBUG,所以任何代码都应该在真正运行起来的时候能够DEBUG其实代码不分好坏,都必须通过测试,通不过测试的代码已经不能以好坏来形容了,根本就是不能用的废品而你想所有代码都可以通过断点调试的形式去debug,这也是不现实的多线程的应用中,很多时候抛异常并不是因为某个单独的代码引起的,而是多线程本身引发的异常,即使你跟踪到出错的代码,也不是说单纯改掉这里就没有异常了,这需要你有全局的把握和分析能力而且多线程中也根本没办法断点一步一步调试
这个与代码好坏无关啊，这是功能需求按你这么说，Thread与backgroundWorker相近，c#的Thread起的线程，也不让你debug了，如何？我郁闷的是：明明直接给我debug就得了，为啥不给？没必要啊
解决方案十二：
多线程的代码可以debug啊，打个断点就行了，但是调试时会在主线程和这个分开来的任务里来回跳，比较麻烦，需要你自己探索调试技巧
解决方案十三：
没什么办法backgroundWorker封装的时候就已经自己加了try,catch,出错就抛异常了,而不会停在出错位置
解决方案十四：
实际上所有有一定规模的程序是必须要加上日志信息的，根据日志信息去定位错误位置和类型，以及缩小调试或分析的范围，这是一种良好的习惯，也必须要养成的习惯。
解决方案十五：
菜单调试》异常把引发那列按需要打勾