异常处理的 catch 语句中，什么情况下需要 messagebox.show 出错误信息，何时要再次抛出异常呢？

Question

异常处理的 catch 语句中，什么情况下需要 messagebox.show 出错误信息，何时要再次抛出异常呢？
------------------------------------------------------
我看到有些异常处理中，在catch语句中，直接显示 e.message，即告诉用户哪出问题了，然后return返回，
但是有些代码中，却是再次抛出新的异常。我不知这是为什么，在哪种情况下需要再次抛出异常呢？

Answer 1

看情况，没一定的。
比如你认为这个异常的发生是不应该的，那你可以直接throw;抛给调用方处理，如果这个异常是内部的，外面根本不关心其意义，可以隐藏掉，用别的方式处理，或是提示用户。

Answer 2

异常可以分为系统异常和业务异常，业务异常必须被转化为业务执行的结果  
DataAccess层不得向上层隐藏任何异常  
要明确区分业务执行的结果和系统异常。比如验证用户的合法性，如果对应的用户ID不存在，不应该抛出异常，  
而是返回（或通过out参数）一个表示验证结果的枚举值，这属于业务执行的结果。但是，如果在从数据库中提取用户信息时，数据库连接突然断开，则应该抛出系统异常  
BL层应根据业务的需要捕获某些系统异常，并将其转化为业务执行的结果  
UI层除了从调用BL层的API获取的返回值来查看业务的执行结果外，还需要截获所有的系统异常，并将其解释为友好的错误信息呈现给用户  
每层都可抛出

Answer 3

一个客户端应用程序应该只有一个地方捕获并且处理异常。其它任何深层次的地方，如果你有闲心一定要包装一次异常信息，new出一个新的Exception子类的实例，继续 throw 出去！

Answer 4

只要你认为会有问题的地方。最好都用try catch 。
至于输出，本人不赞同用MessageBox.show。。
   我建议用Console.writeLine  另外，我还是学生。回答不好请谅解
   

Answer 5

console.writeline是命令行才能用的呀。现在和实际项目，多数都是winform呀。

Answer 6

我们可以随便拿出一个任务的描述来看看，你的主管会在几个任务工单中会告诉你应该随便想当然地以自己的方式处理bug而不抛出？前些天看一个初学（2年c++）的程序员写的一段程序，这一段不长的程序里，遇到服务器连接不上就return false，遇到某个驱动没有正常启动就return false，遇到某个变量没有初始化就return false......总之有6、7个return。短短的程序，无法调试出问题在哪里，它给我们的用户使用以及公司的软件声誉造成了损失时却只知道return false，没有为真正有能力debug的人直接抛出异常（在call stack窗口去调试）。其实进一步看，这种编程的人，就肯定会总想到动不动就messagebox或者console.writeline，还会怎样？

Answer 7

没有为真正有能力debug的人直接抛出异常（在call stack窗口去调试）。?
还是：真正有能力debug的人直接抛出异常（在call stack窗口去调试）。

Answer 8

Console.WriteLine和MessagwBox.Show一样恶劣。sp1234和wuyq11已经说得很明白了。
我不愿意多说，因为架构设计是没有办法向完全没有经验的初学者说明白的。不明白What就没法理解Why，没有理解Why去了解How也是没有意义的。

Answer 9

赞同。另外初学者不要去深究这些。
我说MessagwBox.Show恶劣，初学者说，哦，那就用Console.Write。再说Console.Write不好，那就用Response.Write？
sp1234说一个客户端应用程序应该只有一个地方捕获并且处理异常。
好了，有人看到利用异常陷阱完成一些特定的代码又不解了。学生一开始打好基础。把当下的东西学好，而不是去学一些貌似高深的东西，搞得一知半解。

Answer 10

但是最终交给客户的程序，在顶层是不能抛出异常的呀，必须要处理，不能处理就要给出提示呀。
比如连接服务器失败，应该提示用户，连接服务器失败，请检查原因，是不是网络不通呀？
这时如果再抛出异常，客户的程序就挂了呀。
所以我认为，在深层次可以抛出异常，但是在主调函数中，必须给出提示。异常就是程序中不能处理的地方，你在顶层不提示用户，还能做什么呢？----------------------------------
看过QQ报错么？异常的时候弹出对话框，提示用户发送异常信息?重启?
如果你的软件不确定联网，你有了异常，应当记录到一个异常日志，如果异常严重导致错误，要求用户发回日志，以便开发人员快速定位问题。提示给用户的自然和异常无关，比如：很抱歉软件出错，请保留软件不要卸载联系xxx。这样开发人员联系到客户后有机会找到错误，我个人认为，发布版本的软件如果小公司无法进行完善的测试，有些不容易复现的问题，你需要记录异常信息，在用户出错时反馈完善。

Answer 11

Windows操作系统内核态代码包含很多断言，遇到断言为假，或者无法处理的异常，就会出现蓝屏错误（Stop Error）。为什么遇到这些错误，Windows不吃下去继续运行呢？《Windows核心编程》里面写得很清楚，此时系统出现问题，如果继续运行，会出现更多问题，甚至破坏文件系统，损坏硬件，造成损失，所以最好的办法就是停下来。同样，如果应用程序出现没有办法处理的问题，即使是最顶层，也应该把程序停下来。顶层照样可以抛出异常。

Answer 12

个人感觉，MessageBox.show（）最好少用，除非出现系统严重错误的时候，使用MessageBox.show显示错误信息，然后释放资源，关闭程序，以免占用系统资源，或者是提示用户输入错误的时候，也可以提示输入信息，其他情况，还是不用MessageBox解决异常。

Answer 13

不好意思，说实话，我还是不理解，
举个例子吧。
比如一个 c/s 客户端程序，启动时，网络是好的，正常连接到了服务器 sql server 2000.
然后运行，可是有可能交换机断电了，这台客户机就与服务器失去连接了。这是客户端程序执行一个 select 查询。
大家说这个异常处理应该以什么方式体现呢？1.用messagebox.show("客户机与服务器失去连接，请检查网络连接是否正常！","提示");2.记录信息到日志，我认为，messagebox.show是必须的呀，因为如果不显示，操作员根本不知道为什么操作失败了，是吧。
至于是不是记录到日志，有必要吗？其实给出提示，用户会检查连接，发现交换断电了，接上就行了。然后重启程序继续工作。大家认为我的方法合理吗？如果不合理，用什么方式好呢？

Answer 14

对于你这个问题应该messagebox.show

Answer 15

问题不是你用了MessageBox，而是你在异常处理中使用了MessageBox。如果你的代码无法处理一个异常，你应该交给上层去处理。MessageBox是UI层处理的事情。
如果你的组件被重用到Console程序、Web程序、系统服务、WPF、WCF或者别的什么地方。
如果界面设计者希望用一个自定义的消息框代替MessageBox，或者希望实现静默的用户界面。那么这样的设计就麻烦了。
更加重要的是，如果希望把你的代码放入WorkThread，而不是UI Thread，这样写可能造成程序的死锁。

Answer 16

在程序中，应尽量避免使用try catch抓错误，这好比前面有一个坑，你掉下去，又从坑里爬上来朝前走！
避免try  catch，是绕个弯，再向前走！