关于.net的异常处理try catch 很菜的问题 小弟我我一直不明白，在C#代码中，用try catch和不用 try catch 有上面区别，如果不用的话 ，CLR也会抛出异常啊，和用了之后抛出的异常有上面区别？问题很菜，望各位别耻笑。 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 小弟我我一直不明白，在C#代码中，用try catch和不用 try catch 有上面区别，如果不用的话 ，CLR也会抛出异常啊，和用了try之后抛出的异常有上面区别？问题很菜，望各位别耻笑。 catch异常之后可以把异常写进log 对于已经上线的不方便debug的应用来说这是种常见的做法 然后为了保证程序的正确性 再把异常抛出来 用try catch可以根据异常在程序中做某些处理，比如释放资源、写入日志等 请问 ：抛开 在catch里需要执行操作方法外（如写入日志等），在前天方面 使用TRY和不使用TRY有区别不？比如性能方面？ 性能肯定是有影响的 try catch 其实出异常的时候clr会不断根据调用堆栈往上找 直到碰到一个catch块 然后再回到原来执行的地方继续往下跑 但是你写程序的时候是不知道你catch的地方和抛异常的地方到底隔了多远 这有两个概念——开发调试时期（Debug版本）、发布之后（Release版本）。Release版本程序中通常至少会在最外层自己处理异常。例如主机客户端程序会捕获 AppDomain.CurrentDomain.UnhandledException 或者window service业务服务器会在Receive或者执行每一个消息时的最外层写try...catch....或者asp.net程序会在global.asax中写 void Application_Error(object sender, EventArgs e) { .......................... }等等。为了给用户一个友好的错误界面，而且使服务继续进行下去。否则，应用程序可能就会退出，windows service服务会停止，asp.net网站会重启（所有内存中的数据都丢失），等等。但是在开发调试时，这时候的目的就是尽早地让异常出现，尽可能在异常时让vs调试器立刻停在出错的语句上，而不是自欺欺人地去隐藏异常。因此开发调试时是要取消try...catch....语句。有些人有非常不好的想法，以为使用了try...catch....就可以隐藏程序的问题了。而它让程序以错误的数据、错误的状态继续运行，这种代码就是害群之马，使得之后的程序运行变得诡异、非常难以调试到导致问题的原始语句。碰到这种程序猿就要骂！实际上就算程序运行是没有抛出任何异常，我们往往也在程序中写入很多 Debug.Assert 语句，让程序尽早抛出（迟早要抛出的）异常来。 Release版本必定要在程序最外层处理异常，而不是把异常抛给什么CLR层面。这个不必多说。只是开发中如何管理异常，这个有一点讲究。如果你有项目开发经验，其实反而扯不上性能。写还是不写try..catch这种改变，这是工程上非常需要的。比如说你写一个简单的几行的小程序，调用银行“存款”模块的代码然后验证存款金额正确，并且验证给它不同的错误的输入时它应该抛出异常（而不是执行存款），同时你还要模拟20个线程并行地去对同一个账号存款。那么当程序抛出异常时，你就知道程序错了。如果你想让程序必须抛出异常，那么你就会用try....catch来捕获它的异常并且甚至flag=true，而假设它从未抛出异常则执行到测试程序底部时因为flag==false于是你的测试程序反而要抛出异常了！可见对于测试来说，可能抛出异常算是正常，而没有抛出异常算是异常！假设你有这类测试程序1000个，每天以随机数据（例如随机地到数据库中找到一个账号、随机地选择存款金额）调用测试用例执行10万次，这完全可以是自动化的。比如说你可以中午吃饭时开始运行测试引擎程序，然后等吃完饭之后再来看看测试程序中断到那一个语句上——并且根据bug位置和数据环境来修改程序。异常是程序员的好朋友，没有异常往往你就不知道该在有限的（上班）时间里集中精力做什么了。假设你把每半天的工作计划先写为一个简单的、有着几十条语句的测试程序，你就可以用不断的bug处理流程而驱动出程序来，而不会丧失目标觉得一整天过的无所事事。程序要能够每天都处于“零缺陷”状态，以便随时在两三天之内可以发布，那么就需要柔性地进行项目管理，尽可能让异常尽早抛出来。那种自欺欺人地用try...catch...掩盖开发中程序运行异常，甚至开发时根本不做测试（而仅仅简单地手工“调试”两下），到最后则会悲催地发布毫无质量把握的产品，要么把擦屁股的工作推给别人，要么给自己招来沉重的维护负担。 1.如果不准备处理异常，就不要catch2.一旦catch，就不再throw 按你的说法，我想你应该没有搞清楚"throw e;"和"throw;"这两种写法的差别 你可以catch具体的异常，未知异常自然而然的通过，当然，也可以catch具体的异常后，引发自定义异常，微软提供的各种具体的异常类型，基本够用了，一般地说，受理标准异常，触发的是标准的异常报告处理，可以利用微软的，也可以自己封装另一方面，可以设计一组自定义异常，用于面向用户的异常报告机制 在C#版发一个石子合并问题，看看大家对这类问题的一般思路是什么！ WCF传输dataset的问题。 在button_click事件中怎么启动一个新线程 怎么给自定义的Lable加Click 时间 读取数据库数据问题 关于C#调用VC的DLL的问题，有关类型的，请教一下。 谁能帮忙解释这句话？急 【求 局域网网络流量异常报警系统的设计 可适当付费】 HttpListener获取到IE提交的中文参数乱码 用DrawRectangles怎么画图 vs2010与sql server问题， 这代码问题出在哪，从ashx返回的数据不正确
问题很菜，望各位别耻笑。
{
..........................
}等等。为了给用户一个友好的错误界面，而且使服务继续进行下去。否则，应用程序可能就会退出，windows service服务会停止，asp.net网站会重启（所有内存中的数据都丢失），等等。但是在开发调试时，这时候的目的就是尽早地让异常出现，尽可能在异常时让vs调试器立刻停在出错的语句上，而不是自欺欺人地去隐藏异常。因此开发调试时是要取消try...catch....语句。有些人有非常不好的想法，以为使用了try...catch....就可以隐藏程序的问题了。而它让程序以错误的数据、错误的状态继续运行，这种代码就是害群之马，使得之后的程序运行变得诡异、非常难以调试到导致问题的原始语句。碰到这种程序猿就要骂！实际上就算程序运行是没有抛出任何异常，我们往往也在程序中写入很多 Debug.Assert 语句，让程序尽早抛出（迟早要抛出的）异常来。
如果你有项目开发经验，其实反而扯不上性能。写还是不写try..catch这种改变，这是工程上非常需要的。比如说你写一个简单的几行的小程序，调用银行“存款”模块的代码然后验证存款金额正确，并且验证给它不同的错误的输入时它应该抛出异常（而不是执行存款），同时你还要模拟20个线程并行地去对同一个账号存款。那么当程序抛出异常时，你就知道程序错了。如果你想让程序必须抛出异常，那么你就会用try....catch来捕获它的异常并且甚至flag=true，而假设它从未抛出异常则执行到测试程序底部时因为flag==false于是你的测试程序反而要抛出异常了！可见对于测试来说，可能抛出异常算是正常，而没有抛出异常算是异常！假设你有这类测试程序1000个，每天以随机数据（例如随机地到数据库中找到一个账号、随机地选择存款金额）调用测试用例执行10万次，这完全可以是自动化的。比如说你可以中午吃饭时开始运行测试引擎程序，然后等吃完饭之后再来看看测试程序中断到那一个语句上——并且根据bug位置和数据环境来修改程序。异常是程序员的好朋友，没有异常往往你就不知道该在有限的（上班）时间里集中精力做什么了。假设你把每半天的工作计划先写为一个简单的、有着几十条语句的测试程序，你就可以用不断的bug处理流程而驱动出程序来，而不会丧失目标觉得一整天过的无所事事。程序要能够每天都处于“零缺陷”状态，以便随时在两三天之内可以发布，那么就需要柔性地进行项目管理，尽可能让异常尽早抛出来。那种自欺欺人地用try...catch...掩盖开发中程序运行异常，甚至开发时根本不做测试（而仅仅简单地手工“调试”两下），到最后则会悲催地发布毫无质量把握的产品，要么把擦屁股的工作推给别人，要么给自己招来沉重的维护负担。
2.一旦catch，就不再throw
当然，也可以catch具体的异常后，引发自定义异常，微软提供的各种具体的异常类型，基本够用了，
一般地说，受理标准异常，触发的是标准的异常报告处理，可以利用微软的，也可以自己封装
另一方面，可以设计一组自定义异常，用于面向用户的异常报告机制