Troppa logica in un blocco catch annidato

0

Il mio lead dev si è lamentato del fatto che ho troppa logica in un blocco catch annidato. Il mio codice è simile a questo:

try
{
    // some setup and a network call
}
catch (CustomEx ex)
{
    try
    {
        KindaLengthyRecursiveRetryMethodThatHandlesCustomEx(numTimesToTry);
    }
    catch (AnyException ex2)
    {
        // Log Exception
        throw;
    }
}

KindaLengthyRecursiveRetryMethodThatHandlesCustomEx() effettua la stessa chiamata di rete della prova genitore. Questo è necessario perché non abbiamo modo di sapere che CustomEx si verificherà fino a quando la chiamata di rete fallirà, e se ci sono più cose che non vanno nella richiesta, la chiamata di rete restituirà solo un errore alla volta (da qui il tentativo).

Qualcuno ha un feedback su come migliorare questa struttura di codice?

    
posta khalid13 05.09.2018 - 16:12
fonte

3 risposte

1

Se in pratica stai facendo lo stesso con le x-catch, perché non lo fai nella percentuale inziale try ?

try
{
    NetworkCall(numTimesToTry);
}
catch (Exception ex)
{
    // log this
}

Quindi qualcosa del genere:

void NetworkCall(int maxRetries)
{
    if (!SetupDone())
        DoSetup();

    int retryCount = 0;
    while (retryCount < maxRetries)
    {
        try
        {
            NetworkCall();
        }
        catch (CustomEx ex)
        {
            retryCount++;
            if(retryCount == maxRetries)
            {  
               // log this too
            }
        }
    }
}
    
risposta data 05.09.2018 - 16:21
fonte
4

Con "troppa logica", la mia ipotesi è che il tuo sviluppatore principale non si riferisse precisamente alla lunghezza del metodo, ma piuttosto al fatto che hai una prova / cattura annidata nella tua clausola catch.

Un try / catch annidato non è davvero inefficiente, ma è un po 'brutto da guardare. Prendi in considerazione l'idea di inserire l'intero try / catch nel suo metodo:

try
{
    // some setup and a network call
}
catch (CustomEx ex)
{
    HandleError(ex);
}

...

public void HandleError(CustomEx ex) 
{
    try
    {
        KindaLengthyRecursiveRetryMethodThatHandlesCustomEx(numTimesToTry);
    }
    catch (AnyException ex2)
    {
        // Log Exception
        throw;
    }
}
    
risposta data 05.09.2018 - 16:17
fonte
3

IdentityModel ha un problema simile con i token di aggiornamento

qui ritornano presto se sono buoni, piuttosto che riprovare in una presa:

Generalmente se ti aspetti che si verifichi un'eccezione, probabilmente non dovrebbe essere un'eccezione.

        var response = await base.SendAsync(request, cancellationToken).ConfigureAwait(false);

        if (response.StatusCode != HttpStatusCode.Unauthorized)
        {
            return response;
        }

        if (await RefreshTokensAsync(cancellationToken) == false)
        {
            return response;
        }
    
risposta data 05.09.2018 - 16:29
fonte

Leggi altre domande sui tag