E
Eirik M.
Hi,
I just wonder what people consider to be the best approach when it comes to
propagating exceptions that has occurred in a web-service (or in the layers
used by the web-service). A concrete example may be in place. Let's say that
our web-service lets various clients make updates to a database. Since we're
dealing with optimistic concurrency, once in a while a row may have changed
between a client retrieving the row and updating it. If this happens, a DAL
might throw an exception, e.g. throw (new Exception ("Update failed. Data
changed between retrieve and update). Should the web-service propagate the
exception or should it just return the number of rows affected letting the
client deal with the situation as it sees fit? The latter seems simpler,
especially in scenarios involving single row updates, but somewhere at
MSDN/Architecture I seem to remember reading that they recommend propagating
any exceptions occurring.
Any thoughts?
TIA
--norgie
I just wonder what people consider to be the best approach when it comes to
propagating exceptions that has occurred in a web-service (or in the layers
used by the web-service). A concrete example may be in place. Let's say that
our web-service lets various clients make updates to a database. Since we're
dealing with optimistic concurrency, once in a while a row may have changed
between a client retrieving the row and updating it. If this happens, a DAL
might throw an exception, e.g. throw (new Exception ("Update failed. Data
changed between retrieve and update). Should the web-service propagate the
exception or should it just return the number of rows affected letting the
client deal with the situation as it sees fit? The latter seems simpler,
especially in scenarios involving single row updates, but somewhere at
MSDN/Architecture I seem to remember reading that they recommend propagating
any exceptions occurring.
Any thoughts?
TIA
--norgie