none
Gestione eccezioni entro le librerie RRS feed

  • Discussione generale

  • Buonasera, scusate la (forse) ingenuità del quesito ma sono diciamo autodidatta.

    Sto scrivendo una libreria che fa da tramite tra la mia applicazione finale ed il db sottostante.

    In poche parole la libreria serve a creare un livello di astrazione maggiore leggendo i dati grezzi dal db e presentandoli all'applicazione come oggetti o collezioni di oggetti.

    Ciò premesso, ho dei dubbi su come strutturare la gestione delle eccezioni entro la libreria a seconda della loro causa. Faccio alcuni esempi.

    - Verifica dei parametri passati ai metodi. Se il codice entro il metodo è tale che i parametri non validi causano comunque un'eccezione: conviene lo stesso verificare i parametri sollevando eccezioni tramite la parola chiave Throw in caso di valori non validi? Oppure è meglio lasciare che vengano propagate le eccezioni che il codice stesso genererà?

    - Metodi che accedono in scrittura al db. In questo tipo di metodi ho suddiviso il codice in due sezioni: nella prima raccolgo tutti i dati che mi servono anche tramite lettura sul db, mentre nella seconda, avvio una transazione entro un blocco Try, scrivo i dati eseguendo alla fine il commit (mentre nella sezione catch eseguo il rollback e poi lascio propagare l'eccezione). E' il corretto modo di operare?

    - Eccezioni personalizzate. Ha senso creare un'eccezione personalizzata (che eredita da Exception) quindi intercettare tutte le eccezioni nel codice per riproporle al 'consumatore della libreria' sotto forma di un'istanza dell'eccezione personalizzata? Magari aggiungendo messaggi più pertinenti ed eventuali codici di errore personalizzati. Oppure sarebbe troppo macchinoso oltre che pesante?

    Grazie per ogni eventuale suggerimento.

    giovedì 28 novembre 2019 17:48

Tutte le risposte

  • Buongiorno, 
    Cerco di rispondere con un idea allew domande.

    1. Verifica dei parametri passati ai metodi: Se ci sono eccezioni, meglio vederli per capire il problema. Se non sono importanti - userei Throw;

    2. Metodi che accedono in scrittura al db: - qui, non saprei come consigliare 

    3. Eccezioni personalizzate: C'e senso se sono pertinenti al utente (consumatore). Se invece non li servono, non sarebbero necessari. 

    In ogni caso, se qualsiasi parte aggiuntiva NON serve per altro che FYI, direi che non e necessaria. Se invece l'eccezione potrebbe fermare o bloccare l'applicazione - serve ed e' necessaria. 



    • Microsoft offre questo servizio gratuitamente, per aiutare gli utenti e aumentare il database dei prodotti e delle tecnologie. Il contenuto fornito “as is“ non comporta alcuna responsabilità da parte dell’azienda.

    lunedì 2 dicembre 2019 10:15
    Moderatore
  • Buonasera, grazie per le risposte. Chiedo scusa per il ritardo.
    martedì 24 dicembre 2019 22:47
  • Ciao,

    - Parametri passati ai metodi: una buona regola è "fail fast": se i valori che passi ai metodi (o, ancora più importante, al costruttore) non sono validi, è inutile proseguire, quindi puoi sollevare subito un'eccezione.

    - Metodi che accedono in scrittura al db: direi che il modo di operare è corretto.
    Due osservazioni:

    1. Se la scrittura è strettamente legata ai dati che leggi, forse è meglio mettere tutto in un'unica transazione: potrebbe succedere che, tra lettura e scrittura, qualcuno modifichi i dati che hai letto?

    2. Questo metodo di operare ti porta a scrivere un sacco di codice ripetuto, perché tutti i tuoi metodi saranno composti da: lettura dati, try/catch, begin/commit/rollback, scrittura dati. Forse è più conveniente scrivere un metodo "wrapper" che ti gestisce l'infrastruttura, tipo questo:

    Public Shared Sub RunInTransaction(ByVal connection As DbConnection, ByVal action As Action(Of DbConnection))
        Using tx = connection.BeginTransaction()
            Try
                action(connection)
                transaction.Commit()
            Catch
                transaction.Rollback()
                Throw
            End Try
        End Using
    End Sub

    - Eccezioni personalizzate:

    Secondo me, ha senso solo se la tua eccezione deve contenere dati specifici di contesto della tua applicazione, altrimenti non è così necessario.

    My 2 cents,



    Alberto Dallagiacoma [MCP, MCTS]

    My Italian Blog | Twitter | LinkedIn
    DotDotNet - User Group .NET Emilia Romagna


    mercoledì 25 dicembre 2019 08:18