orenpeled wrote:
Hi everybody!
The following methods return Boolean:
(1) SaveEntity
(2) DeleteEntity
The following methods return Int32:
(3) SaveEntityCollection
(4) UpdateEntitiesDirectly
(5) DeleteEntityCollection
(6) DeleteEntitisDirectly
I understand that (4, 5, 6) should return an indication on the number of updated/deleted records.
However, I can't seem to find a situation in which I pass a collection of entities to save in (3), and it returns a number smaller than the number of the passed entities due to a failure. I would expect an exception to be thrown in this case.
You will get an exception, it just returns the # of entities saved. So if you have a collection and 1 entity isn't changed, you'll get a number lower than the # of entities in the collection.
Same thing about (1, 2) - why should I get False in case of a failure? Wouldn't an exception be more reasonable when failing to save/delete a specific entity?
Only in recursive situations. When the library was originally designed, exceptions were considered to be exceptional, they still are, and therefore if a save fails, an exception would probably cause havoc, while 'false' would signal that the save failed. You will get an exception though in some situations, like when an error occurs inside the db. You won't get an exception when a refetch fails for example, you then will get false. Recursive saves always throw an exception as that's needed to quit the transaction.
It's a thing we didn't change from the beginning to avoid people having applications breaking when an exception was thrown all of a sudden while they didn't expect it.
