Exception handling with expression lambda in Presenter class Following is a code snippet from MVP Win Forms application.

My DAL doesn't handle exceptions and it will be propagated up to the calling method in the presenter classes where the exception will be handled. 

I'm using a single handler called ExecutAction(Action action) so I'm catching exceptions in one place rather than repeating it in every method.

At the moment, I'm not logging errors just alert the user for an action, trying to keep the system alive.

When showing messages to users, Presenters will use static class MessagingService's ShowErrorMessage(). So that I can customize all massage boxes in one place.

    class BankAccountPresenter : BasePresenter
    {
        IBankAccount _Model;
        IBankAccountView _View;
        IDataService _DataService;

        public BankAccountPresenter(IBankAccount model, IBankAccountView view, IDataService dataService)
        {
            _DataService= dataService;
            _Model = model;
            _View = view;

            this.SetViewPropertiesFromModel(_Model, _View);

            this.WireUpViewEvents();
        }


        private void WireUpViewEvents()
        {
            this._view.Search += new EventHandler(_view_Search);
        }

        private void _view_Search(object sender, EventArgs e)
        {
            this.Search();
        }

        private void Search()
        {
            ExecutAction(() =&gt;
            {
                var info = _DataService.GetByACNo(_model.AccountNumber);

                if (info != null)
                {
                    _Model = info ;
                    this.SetViewPropertiesFromModel(_Model, _View);
                }
                else
                {
                    MessageBox.Show ("Bank account not found");
                }
            });
        }



        private void ExecutAction(Action action)
        {
            try
            {
                action();
            }

            catch (NullReferenceException e) { MessagingService.ShowErrorMessage(e.Message); }
            catch (System.Data.SqlTypes.SqlTypeException e) { MessagingService.ShowErrorMessage(e.Message); }
            catch (System.Data.SqlClient.SqlException e) { MessagingService.ShowErrorMessage(e.Message); }
        }
    }


Could you please review the above code and let me know whether this approach is good?

Also could you show me a better way to handle showing user messages than using a static?

Does use of lambda statements in every method (ExecutAction(() =&gt;) degrade code readability? or is it a good practice keep things in one place in this way?
To avoid a discussion in comments I'll go ahead and make my comments an answer.

I think this a much better than your original way. Instead of catching Exception in your DAL, you're allowing all exceptions to propagate up until you can properly handle them. Catching Exception can be a bad thing and is generally considered a bad practice. The problem is that whenever a critical exception such as OutOfMemoryException is thrown, you swallow it and throw a new exception with a message of "Bank account is empty" if I remember correctly. It's just not right because you were hiding what actually went wrong. Your stacktrace would show the exception being thrown from the wrong place and it wouldn't have a meaningful message. 

But that was the past and this is the present. You're handling the exceptions where they should be handled and you're not catching Exception. Those were my only real concerns.

The only thing I don't really like (note it's not actually a problem with your example) is that you handle all exceptions in one method. If one method in your presenter does file IO and another does sql stuff - you'd have to include catches for both types of exceptions in one place. What if your presenter is big and can possibly catch dozens of different exceptions? Is this a problem for you? I don't think so because all you're really doing is displaying the exception message through your MessagingService. I would only see it as a problem if you had to uniquely react to exceptions.