技术性散分：(刚刚知道)同样的效果，两种写法效率竟然差了10倍

Question

如果不是在一个非常大的循环中用到了，还不会感觉出我原来用的方法实在太慢了... 帖出来，以免再有同学犯我的错误
两种写法真的差了10倍的速度。至少///用于
原来的：
internal static object NumericFilter(object src)   //字符串转化为数字，失败返回DBNull
{
    try { return double.Parse(sql + ""); }
    catch { return DBNull.Value; }
}现在的：
internal static object NumericFilter(object src)   //字符串转化为数字，失败返回DBNull
{
    double d;
    if (double.TryParse(sql + "", out d)) return DBNull.Value;
    return d;
}

Answer 1

try..catch本来就是很耗资源,并且效率也比较低的

Answer 2

TryParse 2.0才有吧能不用try就别用try

Answer 3

本人决不用，但是领导指示非要我用try不可，说怕出错，唉，还是听领导的，不然没有money拿了

Answer 4

必须用try的怎么办？只能损失性能了？

Answer 5

cloudppk() ( ) 信誉：100    Blog 
本人决不用，
但是领导指示非要我用try不可，说怕出错，唉，还是听领导的，不然没有money拿了//你是程序员吗?

Answer 6

用不用try 建议看一下微软的一些开发规则啥的
譬如你提供给别人一个函数,按照常规,传入的参数类型和大小都应该是正确的.
这仅仅是应该而已,如果别人恶意调用你的函数(譬如WebService啥的)
你的函数必须有足够的健壮性来处理这些问题,有的地方该用就得用.
(我的意思不是必须用try来处理) 那些说决不用try的 .... 请问你的异常如何捕获呢???

Answer 7

#define Debug
#if Debug
       try
        {
#endif
.........
#if Debug
       }
        catch()
        {
        }
#endif

Answer 8

#define Debug
#if Debug
       try
        {
#endif
.........
#if Debug
       }
        catch()
        {
        }
#endif
请问 加入有这样的操作 
1. 第一步解析传入的参数 ,该参数是一个xml格式字符串
2. 第二步执行打开数据库的操作
3. 第三步根据参数取数据当你执行第三步的时候 你敢保证第一步第二步都一定执行成功?
就拿解析xml参数来说,你敢保证你会把所有错误类型都处理了?

Answer 9

判断传入的参数阿按你说如果，需要传一个0-9的数字参数，我可以用
public bool IsNum(string val)
{
    if (val== "" || val== null)
        return false;
    Regex r = new Regex("[^0-9]");
    return !r.IsMatch(val);
}你的想法是用
public bool IsNum(string val)
{
  try
  {  
    int  i =int.Parse(val);
  }
  catch
  {
    return false;
  }
  return true;
}这个有必要吗

Answer 10

public bool IsNum(string val)
{
  try
  { 
    if (val== "" || val== null)
        return false;
    Regex r = new Regex("[^0-9]");
    return !r.IsMatch(val);
  }
  catch
  {
    return false;
  }
}

Answer 11

用try没问题，但是在循环里用就不好了，如果在很大的循环里用，那就是肯定错了

Answer 12

HOHO   又学习了`
就是少用  TRY`呢```哪个 效率 最低的```
一般 就 用 IF  就好了的呢`

Answer 13

try...catch不在万不得已不要用在这种地方

Answer 14

最好是先正则判断下，如果是数字再转化  这样效率更高
try catch  是耗费资源的

Answer 15

try catch消耗资源，而将try catch用于判断实际上是错误的语义，可能因此MS才增加了TryParse。

Answer 16

能用IFELSE解决的问题，一定不要用TRY。TRY也不是说不能用，有些地方还非他不可呢。例如数据访问的时候，出的错千差万别，只能用TRY来解决。

Answer 17

楼主在误导别人。象楼上的 "能用IFELSE解决的问题，一定不要用TRY。"，说得太绝对了。
单个的try/catch耗时可以忽略不计，比如判断用户在文本框里的输入，用parse和tryparse都是可以的，这种情况下，可读性是第一考虑的因素。只有在大量循环下，才要考虑到try的效率问题。

Answer 18

try catch 是对于 一个 范围很广阔的
异常的处理
因为它检视的范围广 所以 也相对 消耗资源多.TryParse这样的 只是对于 特定类型的 特例
就消耗 相对来说 自然小了很多

Answer 19

TO：
runrunrun(做最好的自己) ( )请看:
hertcloud(·￡孙子兵法￡·)

Answer 20

也就说如果当一大段的代码可能会发生某些异常的时候，才用try&catch？
如果程序员对代码有确定的判断的时候用IF吗？

Answer 21

异常的捕获需要系统监视堆栈信息，所以性能的损失是肯定的
在循环中尽量不要用try，但是单次操作还是建议使用，保证代码的健壮性

Answer 22

学习... 欢迎加入ASP.NET(C#)学习交流QQ群号:①32801051(已满) ②23222074(请不要两个群都加)

Answer 23

好好看看书吧
JAVA有很多这些讲效率的书，C#也有相同类型的书，买本书仔细看看

Answer 24

try 本来就不应该用在转换的时候它应该是用在不可控的异常捕获吧

Answer 25

呵呵，仁者见仁,智者见智了一:如果是做类库开发,需要把错误抛出给客户,让客户去处理,那么只能用Try...Catch了.二:如果是做应用开发,并且你很确定的知道此处代码会出现什么错误,而且不用Try...Catch就可以捕获错误,如楼主的例子,那么就坚决不用Try...Catch了.三:如果不确定会出现什么错误， 而且程序不用Try...Catch的话,会出现一些难以预料的错误，那么还是建议用吧,比如IO操作的错误等等

Answer 26

cloudppk() ( ) 信誉：100    Blog 明显在误导别人

Answer 27

同意try{}catch{}本身不占资源的说法.只在的异常产生时才需要时间.

Answer 28

try的时候应该执行 把中断压栈的操作
不会一点资源都不占

Answer 29

///用于
原来的：
internal static object NumericFilter(object src)   //字符串转化为数字，失败返回DBNull
{
    try { return double.Parse(sql + ""); }
    catch { return DBNull.Value; }
}现在的：
internal static object NumericFilter(object src)   //字符串转化为数字，失败返回DBNull
{
    double d;
    if (double.TryParse(sql + "", out d)) return DBNull.Value;
    return d;
}try...catch...本来就耔资源,但也是出于安全性考虑.
按楼主这样,如果出现异常,就会有问题了.
如果要用改进的方式,最好把传入的值在外层进行安全检查来保证合法性.
鱼和熊掌啊.

Answer 30

用不用try catch ??
先要了解什么是异常，什么是错误