请问大家对错误如何处理？

Question

其实1和2用起来都差不多的,区别仅仅是你到底用if去判断还是try去判断
而且感觉catch的过程会比较卡,所以一般我习惯用if自己做判断
3很少用,除非是函数本身就在form里,否则在类里要直接messagebox.show,一是还要using system.form,二也不是很友好
有些时候,错误可以不用弹窗的形式,而是用label来显示
比如登录框,每次输入错误都弹出个东西,就不如在文本框后面直接红字显示更友好

Answer 1

我 用异常，但是错误信息比较头疼。一般采用lz的方法二，提示给用户的信息放到Gui层，而不是放在异常发生的地方。

Answer 2

此外还有些情况是错误可以用代码来解决的,而不用什么都告诉用户让他自己去解决
比如通信过程中,为防止错误的通信数据更改当前数据,要加各种校验
这个校验过程很复杂,而且各种地方都会调用,所以会用函数的方式
而校验是否成功,一定要返回个bool值让调用它的程序知道
那么这里如果直接抛出异常或者弹出窗体,程序可能就执行部下去了
而现实是,其实程序只要知道数据有问题,就丢弃掉,客户端超时会自动重新发来数据请求

Answer 3

比如我做过的一个虚拟电表通信的项目
用的485通信模拟一个电量电度表
通信过程中要校验命令格式和数据格式
要做各种判断
这些判断都用函数
根据错误的不同,给客户端返回不同的应答这个程序因为是自动在运行,没有人去操作它,只是响应客户端的请求,所以弹出窗口是不可以的,只能自动处理
而且针对不同的错误指令,都要有响应,好让客户端知道发出的指令是哪里不对,避免出现无响应摸不着头脑的情况
所以我也尽量避免直接抛出catch,不让异常抛出到最外层去.那样最外层的catch里要处理的内容太多了

Answer 4

我感觉每个函数带个错误的out参数会不错   把具体的错误抛到最外层  这样你就可以知道具体哪层的问题了

Answer 5

有时我也会这么干,不返回bool型的值,而是返回个string型的值
如果返回值是空,说明运行正常,如果不为空,直接显示字符串就行了.

Answer 6

当然,返回的参数很多的时候,我也用ref 和out 

Answer 7

使用catch有个好处,能将错误信息原原本本的反馈给用户.
甚至能告诉你到底是哪一行出现的错误,错误原因是什么参数错误,或者数组溢出之类的
不过也只是调试的时候有用,直接给用户看有点不友好.用户根本看不懂嘛.
除非是像微软或oracle那种,因为错误信息量很大,而且还要附带解决办法,所以都输出给用户有点不现实
就只能是先返回个错误码,然后让用户自己上网上找对应的错误码如何解决.

Answer 8

有时我也会这么干,不返回bool型的值,而是返回个string型的值
如果返回值是空,说明运行正常,如果不为空,直接显示字符串就行了.
我一般使方法返回bool  消息返回文本 或者其他的对象都可以  这样个人觉得很好用，直接判断方法返回值  成功执行返回true就不用管错误信息了 （因为绝对没有错误信息）  false的时候就去获取错误消息  就OK啦   具体的消息怎么写  那就看自己咯

Answer 9

我比较喜欢用ref out。返回值是bool表示是否成功，错误消息用ref 或out带回来。但有时候用抛异常方便些，可以穿越多层调用，逻辑上好控制，不用判断那么多if.这都得看情况吧。

Answer 10

返回false是很低级的，在30年前的原始的c程序中才会多见。如果你运行一个复杂的程序，你时不时地遇到“xxxx操作没有成功。至于什么原因不知道，反正就没有成功！”这类“莫名其妙”的提示，你说坑爹不坑爹。一个程序，连出错的代码是哪一行都不知道，提示信息都不具体，而且也不能通过vs进行异常中断断点的即时调试（查看调用堆栈、查看每一个入口的变量等等），这种编程是不是很低级？有些人编程只是做课堂练习，因此认为隐藏出错位置、出错原因、“把头埋在沙土里”的这种“返回false”的方法好像挺简单。这种简单是要付出惨痛的代价的。

Answer 11

对于异常的处理确实是一个系统的Very重要的课题。
我的意见是：
底层的方法不需要管处理异常，恰恰相反，它还应该主动地抛出一些异常， 而不是去catch它。
我看到一个同事写的代码，个个方法都加try catch把整个方法的主体框起来，可悲的是，他还觉得这样自己好象是工作很负责似的。对于逻辑上能处理的一些问题，不要抛异常，比如被0除，空引用等等。处理异常应该是上层，甚至是界面层的事情。

Answer 12

try catch显示执行出异常咯