2010-03-12 11 views
10

Quali sono i pro e i contro dell'utilizzo di uno dei seguenti metodi per estrarre un doppio da un oggetto? Al di là delle preferenze personali, solo le questioni che sto cercando feedback su includere la facilità di debug, le prestazioni, la manutenibilità eccpro e contro di TryCatch rispetto a 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; 
    } 
} 

risposta

17
  • TryParse sarà più veloce di cattura un'eccezione
  • TryParse indica qualcosa previsto - niente di eccezionale che sta accadendo qui, è solo che si sospetta i dati potrebbero non essere validi.
  • TryParse non utilizza la gestione per il controllo normale flusso eccezione

Fondamentalmente, andare con TryParse :)

Tra l'altro, il codice può essere riscritto come:

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

GM Jon, Qual è la implementazione interna di tryparse()? È così: provare { Parse(); return true; } catch (Eccezione) { return false; } – Sunil

+2

TryParse passa a String (in realtà un char *), tenta di analizzare quella stringa su un numero (tramite confronti di caratteri), quindi esegue vari altri controlli (intervallo, ecc.) Per garantire che il Numero sia il tipo corretto. Non c'è un blocco di prova attorno ad esso :) –

4

TryParse è più efficiente di prestazioni TryCatch saggio.

2

Avere i metodi Parse lanciano eccezioni su input errati erano un difetto di progettazione. Un input errato è previsto per il comportamento quando si acquisiscono dati da un utente. Il lancio di eccezioni è costoso, non è qualcosa che si desidera eseguire abitualmente nel codice.

Per fortuna, Microsoft ha realizzato l'errore e ha aggiunto i metodi TryParse. TryParse fa non incorre nel sovraccarico di eccezioni che generano input errati, ma il lato negativo è che deve restituire due pezzi di dati, quindi è un po 'scomodo da usare.

Ora, se non avessero creato l'implemetazione rotta Parse in primo luogo, TryParse si chiamerebbe Parse.

1

TryParse è più veloce e di solito meglio, ma vorrei suggerire l'approccio TryCatch nel quadro e back-end di programmazione, perché si può dare più informazioni al cliente circa l'errore:

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

Puoi ancora utilizzare TryParse e aumentare la tua eccezione sui dati non validi. In effetti, dovresti farlo in questo modo, per scopi di tracciamento se non altro. –

+0

Ok, ma avresti solo un messaggio generico sui "dati errati" e perderai le informazioni sul perché i dati sono cattivi. Informazioni contenute in InvalidCastException o FormatException o. Programmando su un dato framework mi piacerebbe il più possibile informazioni su un errore. In ogni caso, quando i dati cattivi potrebbero provenire da un servizio Web o dallo storage, non è un "comportamento previsto" e l'eccezione IMO deve essere generata. – onof

Problemi correlati