This is a follow-up on trouble catching the InvalidColumnKeyException.  Another posting claims the behavior is "by design" but in my scenario it doesn't seem like a good design.

(Earlier post http://ko.infragistics.com/community/forums/t/90920.aspx)

As near as I can tell, the XamGrid occasionally sends out the exception (Infragistics.Controls.Grids.InvalidColumnKeyException) to be thrown on the dispatcher at a later, more unpredictable time.  This happens via a private method Infragistics.Controls.Grids.XamGrid.ThrowInvalidColumnKeyException().  The result is that the exception can't be easily handled.  Appropriate exception handling might include rebuilding the list of XamGrid columns in a different way that would exclude the invalid key.  Hopefully the eventual exclusion of the key would not leave the XamGrid in an unpredictable or inconsistent state.

So here is my scenario.  I have a XamGrid which at one point in time used a bound column with a given Key but since that time the programming has changed so the underlying column data no longer exists.  However, when deserializing a previously saved column layout (via PersistenceManager.Load), the obsolete column key is encountered, albeit briefly.  But there is enough corner-case logic in place that the columns can be rejected, eventually replacing them with the new programming defaults .  Indeed, it is easy enough to catch other exceptions that are thrown in PersistenceManager.Load such as InvalidPersistenceGroupException.  That type of exception is well-behaved and doesn't get thrown via the dispatcher and so it allows corner-case logic to be executed.

Would you agree that it is not ideal for PersistenceManger.Load to crash the application by raising an exception on the dispatcher?  Is there a way to change the behavior if the unbound key is encountered via the method "PersistenceManger.Load"?  Is there a workaround I can use in the meantime?