This is yet another continuation of a thread from the DevForce forums here. The problem is that DevForce will silently swallow any exception that gets thrown by the EntityManager.EntityChanged event if the change was triggered by a query or import. The relevant code looks like this:
internal virtual void OnEntityChanged(EntityChangedEventArgs args)
{
EventHandler<EntityChangedEventArgs> entityChanged = this.EntityChanged;
if (entityChanged == null) return;
try
{
entityChanged(this, args);
}
catch
{
if (args.Action != EntityAction.AddOnQuery && args.Action != EntityAction.AddOnImport)
{
throw;
}
}
}
As mentioned in the forum thread, the behavior of this method has changed a bit overtime. Less things are swallowed now than they were when I first complained about this. But for our application, we really need to know when anything goes wrong. Just because it happened to go wrong when I did a query or an import operation does not mean that I don't care about the exception.
In the last forum post, the rationale for this behavior was:
The argument for swallowing exceptions thrown during AddOnQuery (and AddOnImport) was that "failing in the middle of a query is usually not what the developer actually intended" because it was more likely to occur due to a badly written event handler
Perhaps we aren't usual :-), but in our application, the event handler looks like this:
EntityManager.EntityChanged += (sender, e) =>
{
if (e.Action == EntityAction.AddOnAttach ||
e.Action == EntityAction.AddOnImport ||
e.Action == EntityAction.AddOnQuery)
{
((MyBaseClass) e.Entity).Initialize();
}
};
Any exception thrown here are not going to be because of a badly written event handler. Any exception that gets thrown here is because the entity got very confused while it was doing its one-time initialization logic. And errors in that logic are very important to us.
I can understand that changing this universally might be dangerous and cause other application to start breaking. But if there was some way that we could turn off this behavior or some other way to tell the Entity Manager not to swallow the exception, that would be very, very helpful.
Our previous workarounds are starting to fail as we look to use all our business logic in a Web Service where we can't just rely on error logging to handle this kind of thing. We can't be returning a 'success' response to the caller just because DevForce swallowed a potentially fatal error.
We are on the latest version of DevForce (as of this writing: 2012 - 7.2.3).
Version 7.2.4 contains a flag, EntityManagerOptions.ThrowAllLoadExceptions, to control this behavior. Release notes.