This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello: I'm currently using LightSpeed in my development of a rich client application using the MVVM pattern. Everything is going great, I have a TreeView that implements lazy loading as you expand the child nodes. However, how does one go about handling exceptions from operations on the UOW / Attached Entites? From my knowledge performing operations such as: var myCollection = uow.Collection.Where( collection => collection.Name.Equal( "Something " )).Single(); // Operation on UOW can both be sources of exceptions whether from LightSpeed or the data provider. I've started to wrap certain operations on the UOW ( SaveChanges, Add, etc... ) in a managing class that handles any exceptions however this really doesn't lend itself well to work on Attached Entities. Is there a method I can override to provide exception handling code around operations on my Attached Entities? |
|
|
I figure one solution would be catch any exceptions at the AppDomain, Dispatcher, or Application level depending on application. However, continuing after the exception at this level isn't that easy. So I guess the question still stands, is there a method to work with LightSpeed to handle exceptions in the UOW & Attached Entites close to where they are raised, in order to better determine if I should continue or abort the action? |
|
|
No, there isn't a way to catch exceptions that occur as part of e.g. association traversal. The only thing I can think of it to write custom getters for the association properties: public EntityCollection<Widget> Widgets { For unit of work exceptions, these can be handled by encapsulating the UOW using a repository, and performing exception handling and retry logic within the repository. But this comes at the expense of flexibility because it prevents application code from using the UOW or IQueryable properties directly to perform ad hoc queries (because if app code performed an ad hoc query then the exception would arise in the app code rather than in the repository). You can partially work around this with a bit of LINQ magic e.g. if you want to be able to pass in arbitrary filters then you could make a repository method which accepted an Expression<Func<T, bool>> (or, analogously, a QueryExpression), fed it into the Where operator and ran the LINQ query within an exception handler. If desired, you could also have the method accept ordering expressions, paging info, etc. which it would feed into the OrderBy and Skip/Take operators. This wouldn't provide the full flexibility of LINQ, but would provide a safe way of doing the 90% case. |
|