Parsing sicuro: TryParse vs Parse¶

Parse è rischioso quando non si è sicuri che la stringa sia valida (campo vuoto, utente che non ha ancora inserito nulla, dato sporco).

Perché Parse è rischioso¶

double prezzo = double.Parse(prezzoStr, CultureInfo.InvariantCulture);

Se prezzoStr è vuota (""), null, o contiene qualcosa di non numerico, viene lanciata un'eccezione (FormatException o ArgumentNullException). Nei form SAP, i UserDataSource vuoti restituiscono spesso stringa vuota (non null), quindi il caso capita più spesso di quanto si pensi.

Con TryParse¶

using System.Globalization;

string prezzoStr = oForm.DataSources.UserDataSources.Item("UnitPrice").ValueEx;

if (double.TryParse(prezzoStr, NumberStyles.Any, CultureInfo.InvariantCulture, out double prezzo))
{
    double risultato = Math.Round(prezzo * 2, 2);
    oForm.DataSources.UserDataSources.Item("UnitPrice").ValueEx =
        risultato.ToString(CultureInfo.InvariantCulture);
}
else
{
    // Gestire il caso: valore vuoto o non valido
    SBO_Application.StatusBar.SetText("Prezzo non valido",
        SAPbouiCOM.BoMessageTime.bmt_Short,
        SAPbouiCOM.BoStatusBarMessageType.smt_Warning);
}

Perché NumberStyles.Any¶

L'overload semplice di TryParse accetta di default un formato abbastanza rigido. NumberStyles.Any è più permissivo (accetta spazi, segno, notazione con parentesi per negativi, ecc.) — utile perché SAP a volte restituisce valori con spazi iniziali/finali o piccole variazioni. Per essere più restrittivi si può usare NumberStyles.Float, che copre la maggior parte dei casi reali (numero + decimale + eventuale segno).

Helper riutilizzabile¶

private static bool TryGetInvariantDouble(string input, out double result)
{
    return double.TryParse(input, NumberStyles.Any, CultureInfo.InvariantCulture, out result);
}

Uso:

if (TryGetInvariantDouble(prezzoStr, out double prezzo))
{
    // ok, usa prezzo
}

Regola pratica¶

Stringa che si prevede sempre valida (es. già verificato che non sia vuota) → si può usare Parse dentro un try/catch se si preferisce gestire l'eccezione esplicitamente.
Input utente / campo potenzialmente vuoto o sporco (praticamente sempre, nei form SAP) → usare sempre TryParse: più pulito, non costringe a gestire eccezioni per un caso "normale" come un campo vuoto.