Gestione delle condizioni di errore ignorabili in un metodo

Question

Gestione delle condizioni di errore ignorabili in un metodo

#1 da (2 voti)
#2 da (1 voti)

0

Sto lavorando su un'API approssimativa per eseguire funzioni aziendali di livello superiore. Sotto molte condizioni queste funzioni potrebbero fallire in un modo atteso (non eccezionale), es. la funzione potrebbe non essere in grado di completare a causa del fallimento di una condizione di convalida di qualche tipo.

In molti casi, quello che voglio fare in questi scenari di "fallimento" è di avvisare l'utente e dare loro la possibilità di "sovrascrivere" l'errore. vale a dire, "Attenzione: il trasferimento di potenza di curvatura agli schermi danneggerà l'array di emettitori, sei sicuro di voler procedere?"

Molte di queste funzioni potrebbero avere un elenco di alcune regole di convalida e potrei volerle sovrascrivere tutte.

Quello che sto immaginando adesso è di creare una classe MyResult personalizzata che viene restituita dalle funzioni che include se la funzione ha avuto successo e se non è riuscita, forse un elenco di regole di convalida che non sono riuscite per la funzione. Quindi aggiungere un parametro alla funzione per "sostituzioni" che consente di ignorare queste regole di convalida in una chiamata successiva. Vorrei un feedback su questo approccio. C'è uno schema per questo?

Le funzioni nell'API possono essere chiamate da più piattaforme e l'API stessa è in C #.

error-handling design-patterns

posta scotru 05.05.2014 - 07:23

fonte

2 risposte

Leggi altre domande sui tag error-handling design-patterns

Strategia per mantenere in sicurezza il repository offline usando git [closed] Come simulare un terminale ATM in un POS

score 2 · Answer 1

Non mi preoccuperei. Creerei una seconda chiamata API che non convalida alcuna regola che ritieni debba essere sovrascrivibile dall'utente, quindi il client decida di chiamare prima la logica convalidata, quindi, se l'utente lo seleziona, chiama in seguito il metodo non convalidato . Semplifica notevolmente il problema in modo che non sia necessario avere un sacco di istruzioni if () che avvolgono tutto.

score 1 · Answer 2

Con una logica complessa come quella, renderei la "funzione aziendale" in un oggetto separato, del tutto simile al schema di comando . Quindi, puoi avere un'interfaccia simile a questa:

interface IBusinessFunction
{
    Result Start();
    Result Continue();
    void Cancel();
}

Il Result potrebbe indicare che la funzione è finita o può indicare che l'utente deve eseguire l'override, nel qual caso esegue Continue o Cancel l'intera funzione. Il vantaggio principale di questo consente la gestione generica di tali funzioni nell'interfaccia utente. L'interfaccia utente ha solo bisogno di sapere su questa interfaccia per essere in grado di consentire correttamente l'override o l'annullamento delle funzioni. Inoltre, non è necessario riavviare l'intera funzione ogni volta che viene interrotta e sostituita, perché mantiene lo stato nell'istanza.