[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ADO Exceptions]
I'm starting a new thread on exceptions since we had a few issues with them.
It's not a topical subject at this point of the work on the response, so we do
not have to converge on this issue urgently.
My first suggestion is to clarify two points:
1. What good would exceptions do for ADO clients and ADO itself?
General aspects:
Exceptions help to separate handling results of invocations from handling
errors happened during invocations
Exceptions allow to delay error handling and propagate error signals up in
the stack of invocations. This allows to handle errors at the appropriate level
of abstraction.
Specific aspects:
Exceptions on ADO will allow the ADO client to decide what to do in the
situation of an error.
2. What implies what in the OMA:
(a) an exception implies a particular condition or event (exception x ==>
condition y); or
(b) a particular condition or event implies a particular exception
(condition y ==> exception x)
Why I think it is a good idea to let ADO to raise exceptions when an error
occurs:
-- If we already trust the ADO client to enforce authorization decisions, why
should not we let the client to decide what to do if an error occurs.
-- If the answer to the question #2 is (a) then it can be (and I think should
be) the matter of the enterprise policy to have ADOs to raise exceptions or to
return "no" or to return "yes". As Carol already mentioned in the other tread,
we should not have any assumptions about who and in what scenarios will use
ADOs.
-- A client can always ignore exceptions, so we do not loose anything by
allowing ADO to raise them.
That's it for now.
Any comments?
Konstantin
----------------
Broadcast message to hrac-rfp from Konstantin Beznosov <beznosov@baptisthealth.net>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.