Gestione errori della DI API

Differenza fondamentale rispetto a codice .NET "normale": la DI API non lancia eccezioni .NET per gli errori di business logic (es. "cliente inesistente", "campo obbligatorio mancante", "quantità non valida"). Restituisce invece un codice numerico di errore che va controllato esplicitamente dopo ogni operazione.

Il pattern corretto

int result = oOrder.Add();

if (result != 0)
{
    int errCode = oCompany.GetLastErrorCode();
    string errMsg = oCompany.GetLastErrorDescription();

    // Esempio: log o messaggio all'utente
    Console.WriteLine($"Errore {errCode}: {errMsg}");
}
else
{
    Console.WriteLine("Documento creato correttamente.");
}

Perché è importante saperlo

Se ti aspetti un'eccezione .NET (try/catch) e non arriva mai, puoi facilmente pensare che il codice "non faccia niente" o "funzioni silenziosamente male" — in realtà l'operazione è fallita, ma il fallimento è segnalato tramite il valore di ritorno, non tramite il flusso di eccezioni standard.

Eccezioni "vere" esistono comunque

La DI API può comunque lanciare eccezioni .NET per errori più gravi (es. connessione persa, parametri completamente malformati) — quindi in produzione conviene comunque avvolgere le chiamate critiche in try/catch, in aggiunta al controllo del codice di ritorno, non in sostituzione:

try
{
    int result = oOrder.Add();
    if (result != 0)
    {
        string errMsg = oCompany.GetLastErrorDescription();
        // gestione errore di business
    }
}
catch (Exception ex)
{
    // gestione errore "di sistema" (connessione, ecc.)
}

Recuperare l'ultimo documento creato

Dopo un Add() andato a buon fine, il numero documento non è direttamente sull'oggetto — si recupera così:

if (result == 0)
{
    string newDocEntry = oCompany.GetNewObjectKey();
}