2010-03-12 26 views
10

¿Cuáles son los pros y los contras de usar cualquiera de los siguientes métodos para sacar un doble de un objeto? Más allá de simplemente preferencias personales, las cuestiones que estoy buscando información sobre incluyen la facilidad de depuración, rendimiento, mantenimiento, etc.pros y contras de TryCatch versus TryParse

public static double GetDouble(object input, double defaultVal) 
{ 
    try 
    { 
     return Convert.ToDouble(input); 
    } 
    catch 
    { 
     return defaultVal; 
    } 
} 

public static double GetDouble(object input, double defaultVal) 
{ 
    double returnVal; 
    if (double.TryParse(input.ToString(), out returnVal)) 
    { 
     return returnVal; 
    } 
else 
    { 
     return defaultVal; 
    } 
} 

Respuesta

17
  • TryParse será más rápido que la captura de una excepción
  • TryParse indica algo espera - nada excepcional que está pasando aquí, es sólo que usted sospecha que sus datos pueden no ser válidas.
  • TryParse no está utilizando la dirección para el control normal a excepción de flujo

Básicamente, ir con TryParse :)

Por cierto, el código se puede reescribir como:

public static double GetDouble(object input, double defaultVal) 
{ 
    double parsed; 
    return double.TryParse(input.ToString(), out parsed)) ? parsed : defaultVal; 
} 
+0

GM Jon, Cuál es el implementación interna de tryparse()? Es así: try { Parse(); return true; } catch (Excepción) { return false; } – Sunil

+2

TryParse lanza a Cadena (en realidad un char *), intenta analizar esa cadena a un Número (a través de comparaciones de caracteres), luego hace varias otras comprobaciones (rango, etc.) para asegurarse de que el Número sea del tipo correcto. No hay un bloque try catch alrededor de él :) –

4

TryParse es más eficiente que el rendimiento TryCatch sabia.

2

Tener los métodos de Parse arrojan excepciones sobre la entrada incorrecta era un defecto de diseño. La entrada incorrecta es comportamiento esperado cuando toma datos de un usuario. El lanzamiento de excepciones es costoso, no es algo que desee que ocurra rutinariamente en su código.

Afortunadamente, Microsoft se dio cuenta de su error y agregó los métodos TryParse. TryParse does no incurre en gastos indirectos de excepción en malas entradas, pero la desventaja es que tiene que devolver dos datos, por lo que se siente un poco incómodo de usar.

Ahora, si no hubieran creado la implementación de Parse rota en primer lugar, TryParse simplemente se llamaría Parse.

1

TryParse es más rápido y por lo general mejor, pero yo sugeriría que el enfoque TryCatch en marco y back-end de programación, ya que puede dar más información al cliente acerca del error:

public double GetAge() 
{ 
    try 
    { 
     var input = _dataProvider.GetInput(); 
     return Convert.ToDouble(input); 
    } 
    catch(Exception ex) 
    { 
     throw new MyBackendException(ex); 
    } 
} 
+0

Aún puede usar TryParse y generar su propia excepción en los datos incorrectos. De hecho, deberías hacerlo de esa manera, para fines de rastreo, nada más. –

+0

Ok, pero solo tendrías un mensaje genérico sobre "datos incorrectos" y perderás la información sobre por qué los datos son malos. Información que se encuentra en una InvalidCastException o una FormatException o. Programación en un marco dado Me gustaría la mayor información posible sobre un error. De todos modos, cuando los datos incorrectos pueden provenir de un servicio web o del almacenamiento, no es un "comportamiento esperado" y debe producirse una excepción IMO. – onof