Shoud Lancio le eccezioni al livello dell'interfaccia utente o le gestisco nel mio livello VM

Question

Shoud Lancio le eccezioni al livello dell'interfaccia utente o le gestisco nel mio livello VM

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

6

Considera il seguente metodo:

    public async Task LoginAsync()
    {
        if (!CanLoginAsyncExecute()) throw new ValidationException();

        try
        {
            StartLoading();
            await _authenticationService.LoginAsync(Email, Password);
        }
        catch (LoginException e)
        {
            _logger.Error(e);
            throw;
        }
        catch (ServiceException e)
        {
            _logger.Error(e);
            throw;
        }
    }

Sto avendo difficoltà a decidere se dovessi eliminare le mie eccezioni al livello dell'interfaccia utente che chiama questo metodo o gestisce gli errori qui? È un progetto xamarin personale in modo da poter gestire l'errore nella VM (utilizzando finestre di dialogo o qualcosa del genere). È una buona pratica "silenziosamente" gestire gli errori nel livello della logica di business e rilanciare le eccezioni? Quindi, se il metodo non genera niente, il login ha successo? O dovrei restituire un valore booleano o qualcosa per indicare che l'accesso è andato a buon fine?

design error-handling c# design-patterns mobile

posta tjugg 04.03.2017 - 10:48

fonte

2 risposte

Leggi altre domande sui tag design error-handling c# design-patterns mobile

L'uso corretto del file application.properties? Differenze tra un processo unificato e un piano di progetto Agile?

score 4 · Answer 1

Un errore di accesso non è inaspettato. È probabile che utenti non autorizzati provino ad accedere al sistema. È anche possibile (anche abbastanza comune) che gli utenti abituali facciano errori di battitura o scelgano anche la password sbagliata.

L'interfaccia utente deve quindi essere progettata per reagire in modo appropriato per le situazioni previste, ad esempio dare un secondo e un terzo tentativo. Un progetto logico sarebbe quindi considerare un errore di accesso come uno dei possibili output della logica aziendale invocata.

Si dovrebbero usare eccezioni per gestire situazioni impreviste. Ad esempio, se la connessione al server viene persa o non c'è più memoria. In questo caso è abbastanza normale catturare l'eccezione nel vm e provare a recuperare dall'errore (o limitare il danno). Solo se il ripristino non presidiato ha esito negativo, l'eccezione dovrebbe essere ulteriormente attivata per consentire all'unità di eseguire i propri passaggi di ripristino.

score 1 · Answer 2

Quando si creano classi viewmodel, una delle regole base che promuovo è:

Methods ViewModels which are called by the UI should never™ throw exceptions. Viewmodels should instead express error by changing some public state.

Per il tuo esempio di accesso, ti consigliamo di avere qualcosa come HasLoginError che riflette credenziali errate e probabilmente alcuni che chiamano alcuni re di (Popup)NotificationService che informano l'utente sullo stato del servizio.

Never ™ significa che questo si adatta solo alle situazioni in cui conosci tutte le eccezioni possibili e, naturalmente, solo in quei casi, dove puoi recuperare con garbo.

Ma quasi tutte le mie interazioni viewmodel iniziano esattamente come le tue con un enorme blog di try-catch.