求助 Try Catch的疑惑

杂谈异常处理try-catch-finally没有问题，可以不加；或是有异常，你想要把不同的异常信息进行不同的操作，加上try Catch，去判断

加try可以，但要对未知问题及时处理，比如记录、告知用户等。如果只是catch不处理。那就等着玩蛋吧

我是这样用Try Catch的
在try里面尽可能的避免bug,已经把能想到的异常情况都进行了处理,但我没有信心做到100%没bug
在Catch里面我会将捕获到的错误信息保存为文本文件供之后查看但这样的话所有的代码都需要Try Catch,工作量实在是太大了,而且也很繁琐

发生异常程序会立即退出，要想程序不退出就需要捕获可能出现的异常（try）并处理(catch)。在数据库操作，XML操作和常见的比如除数为0，超出范围等尽量添上try catch。有些异常还需要记录日志。这个看经验了，用得多了，就灵活了。

bs 有 Global 的 Application_Error
cs 的话可以在 Program 下 Application.Run(启动窗体) try 起来,可以捕获异常

try catch 是你觉得这里可能有问题，预料到什么样的问题，这个时候你用try catch帮助处理，不让你的程序崩溃掉
而为之的错误我觉得你需要不要捕获，奔溃掉你才知道你的程序到底有什么样的问题，才能去对应的处理~

try catch 是用来捕获异常的，不是用来处理错误的。写代码要尽可能的把逻辑弄清楚，尽可能的把所有的情况都考虑到。这就是为什么项目中会有tester来做测试要跑case. try catch 在你写code的时候或者在应用某些封装好的方法的时候你可以看出来有exception,所以你要加上try catch 去捕获异常信息，然后做合理的处理。

1.如果你能判断会出什么问题的地方，你就加判断（比如说，对方法参数的校验，大部分都是可以判断出会是什么情况的）；
2.如果不很确定，或者比较懒就用try catch，然后throw 异常；
3.上层代码，会捕捉底层代码往上抛的异常，然后做异常处理，一般是写日志+给用户提示；

try catch 目的是用来发现异常，和处理已知可能发生的异常，并不是说为了让用户看不到错误来掩饰错误；打个比方，你做了一个计算器，肯定不能输入字母吧（前台页面没有做处理的情况下），后台计算的时候，如果用户不小心输入的不是数字，那肯定会报错；如果你是单纯的抛出异常，那就是一串串英文单词，普通用户肯定看不懂；这时就需要你自己做错误处理了，当发现这种输入错误的情况，就提示用户输入数字；异常有很多，有些是已知的，像用户输入字母；已知的，你就要自己去具体问题具体对待，未知道的，你就可以友好的给客户一个提示，例如“服务器正在维护，请稍候再试”；但这个异常，你应该写进日志，方便自己查看修正；

首先，你没有分清楚“程序”是个什么概念。程序是指调试开发阶段的程序？还是Release发布之后的程序？对于前者，程序是调试/测试出来的，不是你自欺欺人地try...catch出来的，因此你需要千方百计进行高效率地调试。对于后者，你需要在进程的“最外层”完善地处理异常（但是这通常不用写try...catch，各种平台往往都有表现层捕获异常的事件，例如 Application.ThreadException 事件），决不能让程序崩溃退出。如果一个公司把调试开发过程当Release来做，那么跟骗子还有什么不一样呢？大骗子即使在技术开发过程中也都以奖励掩盖问题的小骗子为手段，他永远不会真的把产品研发放在第一位。所以，在你Debug阶段，应该使用“条件编译”语句将处理表现层容错的语句去掉，以便进行调试/测试。如果一个程序员不去掉try...catch，那么就不可能有真正进行程序调试的态度，肯定是靠瞎蒙来改错的，甚至根本不知道如何保证每周进行几万次测试的基本技术。

try catch理论上是解决可以预测的问题的,确保不能崩掉.如何你简单的认为不让程序崩掉,也未尝不可.

说白了，调试/测试阶段，去掉 try...catch。程序的Release版本，一定要容错。没有幼稚的“只能说对、还是错”得答案。

我可以说，把程序仅仅看做 Release 程序的公司，很容易滑向骗子行列。

如果没有任何语句是能够保证100%正确,那我真不知道你的程序到底如何编写出来的.比如一个简单的应用:
点下按钮,执行读文件的操作
void button_click(sender,e){readfile(path)}
boob readfile(string path){}
类似读文件这种IO通信的过程,是一定要加try...catch的,因为会出现问题的地方不一定是你的代码出问题,也有可能是通信设备出问题(比如文件正在被外部打开,无法打开文件)
而按钮里,仅仅是调用读文件的方法,并返回成功还是失败,能出什么问题???

如果你的程序使用了不安全的指针,即使加了try...catch也根本捕获不到错误
因为指针出错的话,可能指向的已经根本不是你的程序所在的内存了而如果你使用了多线程,多线程直接操作UI,多线程不安全造成的数据错误,这些也都是try无法捕获的还有类似可能出现的索引超范围(数组溢出)等,都应该能够提前避免,而不是到时候再说.

事实上，lz的疑问深度并没有楼上回复的那么复杂和高大上吧。
简单而言，给一个程序的所有代码都附加try-catch语句是非常不合理的，比如基本语句、加减乘除等基本运算，根本就不应该进行异常捕获，而应该预测到所有可能出现的情况，比如保证不会除0和范围溢出，实在无法预测和控制才使用try-catch语句。
而“事实上,程序所有的代码都无法100%确定是没有问题的”这种想法有点钻牛角尖的感觉，如果非要说执行一个简单的赋值语句：
int a=0;a=3;
万一赋值不成功怎么办？怎么办呢，呵呵。凉拌吧，这不是你应该考虑的问题。try-catch语句滥用的结果不言而喻。
个人觉得还是几条原则：
1.在进行IO操作、远程连接、数据库连接等等一定要附加异常捕获；
2.在不确定代码是否会出现异常时，要进行异常捕获处理；
3.尽可能在代码中控制异常，而不是进行异常处理，比如基本的除0。

int a=0;a=3;
万一赋值不成功怎么办？
->
赋值不成功,就表示你应该重做系统了.
怎么可能赋值不成功呢.内存损坏??有些异常,是try无法捕获的,比如多线程相关,代码逻辑错误,指针错误...
而有些代码,是绝对不会出问题的,比如基本的赋值,判断,循环,这些都可以代码判断数据类型和值是否异常,而代码本身不会出现不可预见的错误
只有通信相关的,因为涉及外部设备,所以就不是代码写的好与不好能够控制的,必须加try

明显扯淡，
比如除数为0的情况，你是通过判断除数是否为0 来解决还是通过try catch 来解决？
况且try catch的执行效率很低，所以建议一般情况下不要加try catch ，可以避免的劲量避免

明显扯淡，
比如除数为0的情况，你是通过判断除数是否为0 来解决还是通过try catch 来解决？
况且try catch的执行效率很低，所以建议一般情况下不要加try catch ，可以避免的劲量避免
+1
所有不可预见的错误都用try接住,明显是不负责任的做法.
到时候就会变成,点了按钮没反应,到底为什么没反应,不知道.
即使在catch里将错误消息输出,也只是报在第几行代码出现了什么类型的错误,你让用户如何解决??

正确的做法是,能够代码判断的地方,都用代码校验
而一些IO操作中,可以预见的错误,但是用代码无法解决的,用try验证
比如打开文件的操作中,事先判断文件是否存在,而不是不管存在不存在就无脑打开
只有当open操作不成功的时候,用try判断一下,失败了说明打不开

读串口,读文件,tcp通信,读数据库这些操作失败,会抛异常.
当然有些封装好的类不会抛异常,而是返回字段表示成功失败应该将会抛异常的代码try,然后判断一下抛什么异常,给用户返回相应的文字说明
比如文件打不开,可能是外部用其他程序打开了.数据库无法访问,可能是网络有问题,让用户检查网线是否插好,等等
不能将最终的错误直接显示给用户拉倒.
那样只是保证程序不退出了,但是什么问题都不解决.
程序是在运行,但是什么都干不了.有什么用?

最好是定义不同的异常类型，预见可能会发生什么问题，就抛什么异常，然后在catch里收集对应的异常

由于一个程序需要长时间不间断地执行，特别是对于那种硬件底层方面的如文件读写、串口类通讯、SOCKET收发等等的操作以及对应数据的操作，可能没办法预计问题出现状况，加try catch是很有必要的。

这个问题的着力点根本不在于“如果不考虑程序区别，应该还是不应该些try...catch？”上。如果你不区分Debug、Release的不同，这就已经说明了问题。比如说你说要些 try....catch 来防止“被零除错误”，那么你程序正常流程中不处理 0 这个数值吗？如果你都是不去在程序业务流程中去判断数据错误，而是需要用比你的一条 if 语句执行起来慢几十倍的系统异常机制去“处理”，这能说明你的程序约来强壮了吗？一个强壮的程序，它是业务“正常流程”上处理了异常数据。绝不是因为抱着“掩人耳目”的目的而使得程序变得强壮。实际上适得其反，小骗子的结果就是早晚一天突然因为一直“带病工作”爆发出来，你找不着改正的办法。

调试易

求助 Try Catch的疑惑

解决方案 »