用判断好还是异常处理好
写程序的时候用判断来标识一个操作是否成功好还是用抛异常好，我看好多java程序都是用抛异常的方式来表示操作失败。c#中应该用那种性能好点

------解决方案--------------------
异常一般是用来处理非正常情况的，如果你的操作没有成功会抛出异常，那么也可以用异常的方式来处理。
------解决方案--------------------
抛异常是不得已而为之的最后手段...事先能想到的情况都应该人工处理...抛异常非常影响性能...
------解决方案--------------------
如果需要的仅仅是个bool则判断判断吧.

如果你还需要其他信息,究竟用bool返回值+string的out参数还是用异常就看具体情况了. 

如果是remoting的话由于异常的远程序列化容易引起安全问题,一般用bool返回值+string的out参数

异常绝大部分情况下性能不如判断高,但是如果你有一个很深层次的调用的话,有些时候异常能够提供更快的跳出(如果中间没有catch,最外面才catch)因为不需要一步一步返回.


具体问题具体分析
------解决方案--------------------
异常如何可以处理就等同于判断，那么就需要用判断的方法来处理。

你知道错在那里了，那么使用判断。
如果你不知道那里将要发生错误，那么使用异常。
------解决方案--------------------
最根本的 要知道 异常 的意思: "就是系统(硬件/软件)可能会出现非正常情况而导致我们的软件运行出错." 所以 异常和判断不是同一个层次的问题.
但是,有一小部分地方,可以利用异常的结构化 简化代码.
------解决方案--------------------
在异常处理上，一般有两个极端的观点，一是不要抛异常，一是有可能就抛异常。其实异常处理上面并不能简单的说不要或者要怎样。

在异常处理上，一般来说有两个原则可以遵守：
1、尽量避免产生异常。
尽量避免产生异常的意思不是说不要去抛异常，而是不要明知道会抛异常还非要去调用。比如说，明知道输入有可能不全是数字，不作任何判断就去int.Parse，这就是不对的。应该用int.TryParse，还有诸如在ASP.NET上的页面输入检查，WinForm的输入检查、输入限制，这些都是避免产生异常的手段。

2、如果不是自己的错，那就异常吧。
初学者在理解异常的时候，经常会把尽量避免产生异常理解为尽量不要抛出异常，结果代码中大量的错误屏蔽，问题都被掩盖。直到某天问题爆发出来便如洪水猛兽一般，一发而不可收拾。
那么什么时候该抛异常而什么时候不该抛异常呢？准确的说原则是：自己能处理的问题便处理，自己不能处理的问题就扔出去。这个比较难于理解，简单的说，在同一个模块中，自己产生的问题自己处理。如果不是自己的原因而产生的问题，则抛出异常。
------解决方案--------------------
异常处理（try）可以保护可能引发错误的代码块，在执行期间检测和响应错误的代码，但相应降低了系统性能;
直接对条件进行判断就会快很多，所以一般能够明确条件范围的情况下使用条件判断就可以了。
------解决方案--------------------
异常，顾名思义，就是用来处理程序中不正常的、不期望出现的情况的。我觉得楼主问此问题，是因为有的时候不太好判断一个情况是属于正常的还是属于不正常的。我的感觉是，如果这种情况不在你的设计范围之内，那显然是异常；如果在你的设计范围之内，但是系统正常运转时出现的几率非常低，也是属于异常；如果某种情况发生以后，破坏的数据完整性无法从中恢复，那显然也是异常；或者一个情况造成的后果造成的影响波及太多的层面，那显然也是用异常合适。还有一点，就是如果一个情况的发生会遍布在代码的很多地方，而你希望处理此问题的代码集中在一点，便于维护，那就得用异常。

首先不要滥用，该用判断的就不要用异常，该用异常的就别用判断。其次，如果两者用哪个都可以，那么用判断能解决的就不要用异常了，显然判断的性能要优于异常。比如参数合法性检查，一般是判断不合法则抛异常。显然单用判断是不好解决的，这里必须用异常。再比如一个方法返回多个状态，那显然用判断然后返回一个类似枚举的值就比较正常，如果你为此定义多个异常来抛，那显然有点滥用异常了。
------解决方案--------------------
寫開發類用異常，寫應用，商業邏輯用判斷