CslaDataProvider swallows errors? Or something else?

ajj3085 posted on Wednesday, April 30, 2008

Hi,

I'm just getting started with the CslaDataProvider.  Here's my Xaml:

    <Window.Resources>
        <Csla:CslaDataProvider
            x:Key="ApplicationList"
            ObjectType="{x:Type Deployment:ApplicationList}"
            ManageObjectLifetime="False"
            FactoryMethod="GetApplications"
            IsAsynchronous="False"
        />
    </Window.Resources>

The problem is that while the Factory method is properly being called, if there's any exception thrown in the process, nothing seems to happen.  My window opens and displays, but empty.  Shouldn't an exception be coming through somewhere?  What's going on?

Thanks
andy

Paul Czywczynski replied on Wednesday, April 30, 2008

WPF will not not throw up an exception dialog when there are binding errors. The output window is your friend when designing WPF forms. VS will show the binding exceptions/errors in the output window. Most of my team keeps the window open on an other monitor during debugging sessions. If that doesn't work for you, try Josh Smith's Mole plugin for VS and/or create a simple pass-thru converter to use in your binding expression and set a breakpoint in the converter to look at your live data in VS's locals window.

ajj3085 replied on Thursday, May 01, 2008

Ugh.  That's a problem.  If my factory method throws an exception, I need to display an access denied message to the user.  Also, for any other unhandled exceptions, in my WinForms application I have my own error dialog and handling (which emails me exception details). 

Since most of the errors happen during data access, that's going to make informing the user much more difficult.

Paul Czywczynski replied on Thursday, May 01, 2008

Here is some code on how we handle it. We resorted to manually coding all our databinding. It uses a lot of our own functions but you see the paradigm we use:

        protected override void DataBindForm()
        {
            using (_odp.DeferRefresh())
            {
                _odp.ObjectType = typeof(EmployeeDetails);
                _odp.FactoryMethod = "GetEmployeeDetails";
                _odp.IsAsynchronous = true;
                _odp.DataChanged += new EventHandler(Odp_DataChanged);
                _odp.FactoryParameters.Add(this.CurrentPageJournalItem.PrimaryKey.OriginId);
            }
        }

        private void Odp_DataChanged(object sender, EventArgs e)
        {
            if (_odp.Error != null)
                Helpers.ExceptionHandler(_odp.Error);

            if (_odp.Data != null && this.DataContext == null)
            {
                this.DataContext = _odp;
                (_odp.Data as EmployeeDetails).PropertyChanged += new PropertyChangedEventHandler(Details_PropertyChanged);
            }
        }

        private void Form_Unloaded(object sender, RoutedEventArgs e)
        {
            this.SaveCompleted -= Form_SaveCompleted;
            (this._odp.Data as EmployeeDetails).PropertyChanged -= Details_PropertyChanged;
            this._odp.DataChanged -= Odp_DataChanged;
            this._odp = null;
        }

ajj3085 replied on Thursday, May 01, 2008

So the solution is to hook into the DataChanged event and check errors there.. seems easy enough, although it should be unnessary.

RockfordLhotka replied on Friday, May 02, 2008

That is the solution - and it makes sense if you think about all the options.

The CslaDataProvider (or any data provider for that matter) is not invoked by your code. So you can't wrap it in a try..catch block. So there must be some eventing scheme by which it notifies you of any issues. They chose to consolidate all notifications into the single DataChanged event rather than having various events for success/fail/etc.

Then consider that some data providers (including CslaDataProvider) support asynchronous loading of data (IsAsynchronous="True") - a feature that seriously rocks!! But in that case things are even more fun because not only is the data provider not invoked by your code, but it runs on a background thread. So dealing with issues could be even more complex, but they aren't, because the same eventing model services this scenario as well.