5

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?

1
  • Usually login errors are not exceptions and are handled more like validation errors. Mar 4, 2017 at 14:13

2 Answers 2

4

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.

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.

1
  • 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
    Mar 6, 2017 at 7:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.