C#: ¿Cuándo debería usar TryParse?

Question

Entiendo que no arroja una excepción y por eso podría ser más rápido, pero también, es muy probable que lo esté usando para convertir datos de entrada a datos que puede usar, así que no creo que se use tan a menudo para hacer una gran diferencia en términos de rendimiento.

De todos modos, los ejemplos que vi son todos a lo largo de las líneas de un bloque if/else con TryParse, el otro que devuelve un mensaje de error. Y para mí, eso es básicamente lo mismo que usar un bloque try/catch con el catch devolviendo un mensaje de error.

Entonces, ¿me falta algo? ¿Hay alguna situación en la que esto sea realmente útil?

Answer 1

Es casi tan simple como esto: Use Parse si desea una excepción cuando encuentre datos no válidos; use TryParse si no lo hace. Por lo tanto, su pregunta parece ser:

¿Por qué no desea una excepción si los datos no son válidos?

Las excepciones solo deben utilizarse para casos excepcionales, y la invalidez de los datos puede no ser un caso excepcional.Tal vez esté escribiendo un programa de limpieza de datos que espera obtener datos no válidos e intentará inferir qué valor razonable tiene cuando los datos no son válidos. Tal vez los datos no son tan importantes y puedes omitir el registro que lo contiene.

Depende del contexto, y teniendo la elección de Parse y TryParse métodos le permite elegir el mecanismo de análisis apropiado para la suya.

Answer 2

Donde sea posible, use TryParse - usarlo es mucho más barato que obtener una excepción.

Answer 3

Aparte del aspecto de rendimiento que usted ha mencionado usted mismo, también hay una diferencia semántica:

El uso de try/catch es para circunstancias excepcionales. Ingresar datos no válidos es algo que esperas, no algo excepcional.

Answer 4

Si necesita establecer un valor predeterminado en el análisis fallido, TryParse junto con un if es una excelente manera de hacerlo.

Answer 5

Para los casos en los que no le importe establecer el valor en 0 en un análisis fallido (tal vez entrada no válida) o en los casos en que desee brevedad, el código de retorno de TryParse lo permite.

Answer 6

Bien int.TryParse devuelve un bool que le permite probar si fue exitoso en lugar de detectar una excepción. Usualmente lo uso en situaciones en las que si la información se tradujo con éxito, quiero usarla, pero si no es importante, puedo ignorar el error en la medida en que quiera usar un valor predeterminado a menos que tenga un significado valor en cuyo caso lo anularé, pero si el valor no fue significativo, mantendré el valor predeterminado.

La teoría dice que las excepciones son intrínsecamente costosas y, por lo tanto, no debe usarlas para dictar el flujo del programa. Debes atraparlos donde algo es semánticamente incorrecto, en lugar de algo que pueda interpretarse como flujo de datos.

Answer 7

Cada vez que realice un análisis, ya que es bastante menos costoso de usar que una Excepción, además, puede hacerlo parte de una simple declaración si en lugar de un gran intento ... atrapar bloque.

Answer 8

No soy un mono C#, pero ...

Una excepción interrumpe el flujo de código normal mediante la transferencia de procesamiento al bloque catch.

TryParse le dará más control (por ejemplo, resaltar un error en un cuadro de texto) en lugar de confiar en el mecanismo de excepción.

Answer 9

Si está validando la entrada en un formulario, puede establecer el ErrorProvider en el control (o un MessageBox o alguna otra notificación) cuando devuelve falso. No es un caso excepcional porque, como han dicho otros, debes planearlo.

Answer 10

Supongamos que está leyendo un archivo de registro:

public IEnumerable<LogEntry> GetAllValidEntries() { 
    while (!logReader.Finished) { 
     string nextLine = logReader.ReadLine(); 
     LogEntry nextEntry; 

     if (TryParseLogEntry(nextLine, out nextEntry)) 
      yield return nextEntry; 
    } 
} 

private bool TryParseLogEntry(string line, out LogEntry logEntry) { 
    logEntry = null; 

    if (string.IsNullOrEmpty(line)) 
     return false; 

    string[] cells = line.Split(';'); 
    if (cells.Length < 3) 
     return false; 

    DateTime time; 
    decimal price; 
    int quantity; 

    // We just want to read this line of text as a LogEntry 
    // IF it is valid; otherwise, there's no reason to throw 
    // an error in the user's face 
    if (!DateTime.TryParse(cells[0], out time) || 
     !decimal.TryParse(cells[1], out price) || 
     !int.TryParse(cells[2], out quantity)) 
     return false; 

    logEntry = new LogEntry(time, price, quantity); 
    return true; 
} 

Dado que todo el propósito del código anterior es extraer elementos válidos de una secuencia (que presumiblemente se espera que contienen algunos elementos no válidos), Creo que los métodos TryParse hacen un lote más sentido en este caso que los métodos Parse, que exigen una entrada válida.