try catch怎么用才好

[jthkl]

写一个程序，各种数据库,io操作，按道理都应该加个try模块。问题是也太繁琐了吧，每次都加try复杂点的程序加上几十几百个也不多，我想问有没有比较高效的方法，不用加这么多try代码，同时在程序出错时又能把详细信息反馈给用户。

[jthkl]

我开发的是winform程序，若将try放在main里边

            try
            {
                Application.Run(new Form1());
            }
            catch (Exception ex)
            {

                MessageBox.Show(ex.Message);
            }

在form1里出现错误

        private void button1_Click(object sender, EventArgs e)
        {
            int a = 1;
            int i = 1 / (a-1);
        }

则form1窗体会退出，然后才会提示message，之后程序退出。

之前接触过金蝶eas，那个程序出现可预见的逻辑错误就给出信息让用户处理，若是不可预见的就给出用户看不懂的栈信息，无论在哪里出错，是哪种错误，都会显示统一的窗体（虽然是用java做的，我想c#也可以吧），不知道这种效果怎么实现。

[jthkl]

另外这个eas出现错误是不会导致整个程序退出的，你把错误提示窗体关闭，还可以继续进行正常操作，而导致错误的那一步，就算你没做
不知道怎么搞的。

[exception92]

出错时如果抛出的异常不能被执行线程捕获，则整个应用程序都将退出。只能说开发一开始都没有日志模块的规划。

[正怒月神]

你说的是全局异常吧。 你是什么项目？ mvc的话，当初我使用2个方案。 你自己稍微改一下。 https://blog.csdn.net/hanjun0612/article/details/49022085

[兔子家族-二哥]

引用 楼主 jthkl 的回复:

写一个程序，各种数据库,io操作，按道理都应该加个try模块。问题是也太繁琐了吧，每次都加try复杂点的程序加上几十几百个也不多，我想问有没有比较高效的方法，不用加这么多try代码，同时在程序出错时又能把详细信息反馈给用户。

喂喂喂，你要搞清楚你数据库返回的错误信息客户是看不懂的好吧？！我问你你数据库报错 varchar 类型 不能转成 int 类型，你把这句话返回给客户，他晓得是啥意思？你应该去做每个参数的校验是很有必要的！如果参数都对了还能执行失败直接返回服务器连接失败就是妥妥的

[huakai2418]

业务错误自己校验，程序错误就统一try catch后记录日志，至于在哪儿可以统一try catch呢，winform应该是有application的error，asp.net也有统一的error，可以截获后做日志记录

[以专业开发人员为伍]

引用 楼主 jthkl 的回复:

写一个程序，各种数据库,io操作，按道理都应该加个try模块

表现层框架通常都会有统一的捕获异常的事件，例如 WinForm 可以在 Application.ThreadException 事件中处理异常，而 asp.net 可以在 HttpApplication 对象实例的 Error 事件中处理，控制台程序可以在 AppDomain.CurrentDomain.UnhandledException 事件中处理，等等。

自己写的类库，说“按道理都应该加个try模块”这通常是初学者误传的。当你写一个特别简单的没啥复杂设计的东西时，你觉得好像有点方便又拿不定的，你所得到的往往也是误传的东西。

在自己写的类库中，尽量不要写 try。应该自动抛出给上层处理，你无需写这种代码。有的人甚至胡乱写一个 try 然后在catch中仅仅写一行 throw; 这就更荒唐了，这除了妨碍了 vs 的调试器正确捕获调试堆栈对象以外没有任何作用，这使得开发人员丧失了调试能力。

[以专业开发人员为伍]

初学者有一个很不好的“理由”就是认为 try 是可以对用户隐藏自己的尴尬，从而让自己不用去仔细测试程序 bug 的。这可以说是“人品”问题，需要从一开始就杜绝。程序的 Relase 版本当然是要在表现层捕获异常，例如在 Application.ThreadException 事件处理中给用户一个提示，然后继续运行程序。但是这仅仅限于 Release版本，而在 Debug版本，也就是开发人员使用的版本，是应该禁用这种捕获的。也就是使用“条件编译”宏指令来封装两个代码版本，在 Release 版本中才有这个捕获代码。

在 Debug 版本中，开发人员每天的工作就是要让 bug 尽早地跳出来，甚至测试人员千方百计地让 bug 跳出来。只有让 bug 尽早跳出来，我们才知道开发人员最应该作得下一步工作是什么方向。如果开发人员目地就是写 try 来糊弄自己的领导，而不是仅仅为了 Release 版本让用户继续使用而写try，那么这种开发人员我的原则是倾向于开除。这确实不是小事儿，过度地写 try 代码这种恶习代表着千方百计消极怠工地避免写正确解决了 bug 代码，并带着病毒来传染的习惯，在团队中就好像几粒老鼠屎毁坏了一锅汤一样会传染出很糟糕的结果。

[以专业开发人员为伍]

极个别的地方是要在业务逻辑中写 try...catch 代码的，例如当我们调用其它人的远程通讯服务功能，但是对方的程序员有些人太不负责任，或者是一些硬件或者系统原因，造成对方偶尔会返回错误数据而造成我们的程序底层api（框架层）崩溃，当遇到这这种错误时，我们可能需要屏蔽对方错误，这就是要写 try....catch。这是极少数情况下会出现的，算是我们无法用代码预先屏蔽和拦截的 bug，只能通过系统错误机制来捕获。

一般来说，不要逆向使用系统错误处理栈。编程设计要顺势顺着框架的设计初衷去设计，不要为了（自以为）省事儿而逆势编程。