Това е още едно продължение на тема от форумите на DevForce тук. Проблемът е, че DevForce тихо ще погълне всяко изключение, което се хвърля от събитието EntityManager.EntityChanged, ако промяната е била задействана от заявка или импортиране. Съответният код изглежда така:
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;
}
}
}
Както бе споменато в нишката на форума, поведението на този метод се промени малко с времето. Сега се преглъщат по-малко неща, отколкото когато за първи път се оплаках от това. Но за нашето приложение наистина трябва да знаем кога нещо се обърка. Само защото се е случило да се обърка, когато съм извършил заявка или операция за импортиране, не означава, че не ме е грижа за изключението.
В последната публикация във форума обосновката за това поведение беше:
Аргументът за поглъщане на изключения, хвърлени по време на AddOnQuery (и AddOnImport), беше, че „провалът по средата на заявка обикновено не е това, което разработчикът всъщност е възнамерявал“, защото е по-вероятно да се случи поради лошо написан манипулатор на събития
Може би не сме обикновени :-), но в нашето приложение манипулаторът на събития изглежда така:
EntityManager.EntityChanged += (sender, e) =>
{
if (e.Action == EntityAction.AddOnAttach ||
e.Action == EntityAction.AddOnImport ||
e.Action == EntityAction.AddOnQuery)
{
((MyBaseClass) e.Entity).Initialize();
}
};
Всяко изключение, хвърлено тук, няма да е поради лошо написан манипулатор на събития. Всяко изключение, което се хвърля тук, е, защото обектът се е объркал много, докато е изпълнявал логиката си за еднократна инициализация. И грешките в тази логика са много важни за нас.
Разбирам, че универсалната промяна на това може да е опасна и да доведе до счупване на други приложения. Но ако имаше някакъв начин, по който можем да изключим това поведение или някакъв друг начин да кажем на Entity Manager да не преглъща изключението, това би било много, много полезно.
Нашите предишни заобиколни решения започват да се провалят, тъй като търсим да използваме цялата си бизнес логика в уеб услуга, където не можем да разчитаме само на регистриране на грешки, за да се справим с този вид неща. Не можем да връщаме отговор „успех“ на повикващия само защото DevForce е погълнал потенциално фатална грешка.
Ние сме на най-новата версия на DevForce (към писането на това: 2012 - 7.2.3).
EntityChanged
изобщо не се използва от DevForce...така че не мисля, че трябва да се тревожим, че тази промяна засяга стандартното поведение на DevForce . - person Stephen McDaniel   schedule 23.07.2014