111,092
社区成员
发帖
与我相关
我的任务
分享关于Try，Catch的正确用法？
http://bbs.csdn.net/topics/391053174
看了SP的 回复，那么到底正确的catch应该怎么使用
看了SP的 回复，那么到底正确的catch应该怎么使用
...全文
请发表友善的回复…
发表回复
vampireshj 2015-06-20
- 打赏
- 举报
个人认为如果认为上层接口可以处理，那就把异常往上抛出，如果上层处理不了，比如网络中断，数据库连接异常。则可以使用tre catch捕获
不知不觉后知后觉 2015-06-17
- 打赏
- 举报
论坛怎么回帖？
weixin_29108001 2015-06-17
- 打赏
- 举报
领教了领教了
於黾 2015-06-16
- 打赏
- 举报
而如果是统一弹出个错误信息,那就跟不对
首先,如果你是服务端程序,弹出信息根本没人能看得见
其次,如果你是客户端程序,也应该是UI负责弹出错误信息,而不是最低层的某个函数直接弹出
於黾 2015-06-16
- 打赏
- 举报
正确的catch应该这样用
try
{
}
catch (ArgumentException e1)
{
}
catch (SocketException e2)
{
}
catch (IOException e3)
{
}
catch(Exception e4)
{
}
针对每一种可预知的故障类型,不同的业务逻辑去处理
如果你统一throw抛出,那就跟没加try,catch没有任何区别
如果你统一不抛出而只返回个成功失败,那就没法调试,根本不知道到底什么原因出错了
wish907 2015-06-16
- 打赏
- 举报
中枪，有一次就是这个原因
leeya66 2015-06-16
- 打赏
- 举报
异常先手还是用户体验角度考虑，不能出现程序死机什么的
wish907 2015-06-16
- 打赏
- 举报
你这是事后补救,处理BUG的思路.跟软件正常的try,catch不是一回事
加try,catch并不是为了解决bug问题
如果你在调试阶段,不加try,反而更容易找到bug在哪里,编译器就会自动断点在出问题的代码行上,省了你自己翻日志还找不到具体的原因
而如果真正运行,很多情况都会导致底层抛出异常
这些一般都是IO操作引起的
比如写文件失败,比如连接数据库失败,比如连接以太网失败,比如以太网读取数据超时
类似这种问题,就应该通过try捕获异常,然后程序自动进行重试,而不是遇到啥P大的问题都给用户弹出个对话框
用户看不懂,也不知道该如何解决.
这种异常写进文件也没用.因为是很正常的现象,而不是什么bug[/quote]
感觉可能这个就是说出了我想要的，再挂两天结贴吧
於黾 2015-06-16
- 打赏
- 举报
还是举个简单的例子,不要泛泛的来说,可能更能理解
比如一个简单的功能,判断文本框里输入的是不是数字
这里有很多种做法,比如正则,比如int.TryParse()
假如我就用最笨最简单的办法来判断
try
{
int i=Convert.ToInt32(TextBox1.Text);
}
catch
{
MessageBox.Show("输入的不是数字");
}
很显然这里不可能出现别的什么异常,只会是文本转数字有错误
那么就不要把真正的错误信息(包括代码行什么的)显示给用户
更不用写日志
所以还是强调,具体问题具体分析,不能一概而论
sgyiliya 2015-06-16
- 打赏
- 举报
我一般的做法是，用try catch来记录日志，结合microsoft的Practices里面包装好的方法来写日志，这个日志可以精确到具体是哪一行代码遇到异常。
於黾 2015-06-16
- 打赏
- 举报
准确的说法应该是
能够预知到错误发生的类型,但是无法预知到什么时候会出现问题,所以需要加try,在catch里代码解决能预测的类型
当然最后无法预知的类型也要捕获,这部分可能就需要通过弹出错误信息,写日志,事后来补救了
冰冷的小爪 2015-06-16
- 打赏
- 举报
正解！
try{}catch{}不是用来避开BUG的，应该是用来控制程序员不能预判的部分的，能预判的在前几个catch中都可以解决 了
於黾 2015-06-16
- 打赏
- 举报
问题是你不可能预知到异常的发生
很多异常是可以预知的,比如除0错误,判断一下就好了,不要等除以0了在抛异常
而所有IO操作,都依赖于外部设备,跟你自己的代码关系不大(除非有严重BUG)
你在通信之前,没法预测本次通信到底能不能通的上啊
xuzuning 2015-06-16
- 打赏
- 举报
异常处理本就是个辅助手段
如果你能预知异常的发生，那么本该在发生前就处理掉，而不是等到发生时再处理
所以在 Catch 中写日志是正确的做法
在最高层用一个 Try ... Catch 就足够了
於黾 2015-06-16
- 打赏
- 举报
其实这种应用,在日常生活中就有很多的
比如QQ
并不是一断线就立即给你弹个框出来告诉你掉线了
而是先自动重连,超时了还连接不上,才会告诉你网络有问题了
具体问题要具体分析,个别处理
不能不管是啥问题都丢给用户,也不能都丢进日志就完了
於黾 2015-06-16
- 打赏
- 举报
当然,也不是无休止的重试
比如读取数据库,重试了3遍还是连不上
那么就应该弹出对话框,告诉用户,网络有问题,或者数据服务器有问题,找网络管理员解决吧
偶发的问题就自动重试,可能重试一次就好了,这种事情就不要骚扰用户了
於黾 2015-06-16
- 打赏
- 举报
你这是事后补救,处理BUG的思路.跟软件正常的try,catch不是一回事
加try,catch并不是为了解决bug问题
如果你在调试阶段,不加try,反而更容易找到bug在哪里,编译器就会自动断点在出问题的代码行上,省了你自己翻日志还找不到具体的原因
而如果真正运行,很多情况都会导致底层抛出异常
这些一般都是IO操作引起的
比如写文件失败,比如连接数据库失败,比如连接以太网失败,比如以太网读取数据超时
类似这种问题,就应该通过try捕获异常,然后程序自动进行重试,而不是遇到啥P大的问题都给用户弹出个对话框
用户看不懂,也不知道该如何解决.
这种异常写进文件也没用.因为是很正常的现象,而不是什么bug
wish907 2015-06-16
- 打赏
- 举报
和我一样，所以我们都还是新手
chuchenghao1989 2015-06-16
- 打赏
- 举报
习惯所有的catch ex都打印到日志。这样也不怕出问题有问题查找不到。
衣舞晨风 2015-06-15
- 打赏
- 举报
加载更多回复（10）
