Shoud I throw exceptions to UI layer or handle them in my VM layer

Question

Consider the following method:

    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;
        }
    }

Im having a hard time deciding should I throw my exceptions to the UI layer that calls this method or handle the errors here? It's a personal xamarin project so I could handle the error in the VM (using dialogs or something). Is it a good practice to "silently" handle errors in the business logic layer and rethrow the exceptions? So pretty much if the method doens't throw anything, the login is successful? Or should I be returning a boolean or something to indicate the login was successful?

Usually login errors are not exceptions and are handled more like validation errors. — Greg Burghardt
– Greg Burghardt, Commented Mar 4, 2017 at 14:13

Christophe · Accepted Answer · 2017-03-04 20:38:30Z

A login error is not unexpected. It is probable that unauthorised users might try to access the system. It is also possible ( even quite common ) that regular users make typos or even pick the wrong password.

The UI therefore should be designed to react appropriately for the expected situations, for example give a second and a third attempt. A logical design would therefore be to consider a login failure as one of the possible output of the business logic that was invoked.

Exceptions should be used to handle unexpected situation. For example if the connection to the server is lost, or there's no mor memory. In this case it is quite normal to catch the exception in the vm and try to recover from the error (or limit the damage). Only if this silent recovery fails, should the exception be thrown further to let the Ui take its own recovery steps.

Kai Brummund · Accepted Answer · 2017-03-05 21:56:44Z

1

When building viewmodel classes, one of the basic rules I promote is:

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

For you login example, I'd recommend having something like HasLoginErrorreflecting wrong credentials and propably some calling some king of (Popup)NotificationService informing the user about the service state.

Never™ means, that this only fits to situations where you know all possible exceptions and of course only in those cases, where you can recover gracefully.

But almost all of my viewmodel interactions start exactly like yours with a huge try-catch blog.

answered Mar 5, 2017 at 21:56

Kai Brummund

1213 bronze badges

How I actually decided to go with was making a new exception class UiException which are thrown to the ui. So the UI Layer only has to catch UiException and it has a enum property which indicates which kind of error it is (login, setting profile etc..). Don't know if this is the right way to go but I'll go with this until i'll find good examples of this. Im sure your way is also right and maybe I will try it next time :) Thanks for the input.

tjugg
– tjugg

2017-03-06 07:01:37 +00:00
Commented Mar 6, 2017 at 7:01

Add a comment |

Stack Exchange Network

Shoud I throw exceptions to UI layer or handle them in my VM layer

2 Answers 2

Your Answer

Hot Network Questions

Shoud I throw exceptions to UI layer or handle them in my VM layer

2 Answers 2

Your Answer

Sign up or log in

Post as a guest

Related

Hot Network Questions