This content has been marked as final. Show 2 replies
- (q1) Why does the "... so problems can be handled locally inside a task flow ..." idea (of encapsulation) apply only to ADF Controller error handling and not to ADF Model error handling?
Good question. Let me try an dexplanation.
From a design perspective, DataBindings.cpx files are merged at runtime to one instance at runtime (there always is a single BindingContext at runtime), which is why the error handler defined in an ADF library would cause a conflict with the one defined in the base application if loaded instead. The Error handler in DataBinding.cpx is comparable to the global task flow exception handler (https://blogs.oracle.com/jdevotnharvest/entry/extending_the_adf_controller_exception_handler) which also there is only one instance at a time and not to the error handler activity in a task flow (which is a control flow logic).
I think a challenge for modularizing the binding context error handler would be to tell which error handler class needs to be referred to to handle an exception unless there is a traceable relationship between the "exception & error code", the data control and the DataBindings.cpx file containing the error handler class reference. I could imagine that if this relationship would exist then a delegation pattern could be used to handle this. However, exceptions that are spawned by the business model don't know about the DataControl exposing it (or the DataBindings.cpx file). Not sure if there is a good solution to this or if there is a real requirement for it.
I think that what I describe in the article should maybe be filed as an ER/Bug to strip out or ignore ErrorHandler defintiions in DataBindings.cpx files that are not in the base application to avoid confusion, which would require the class loader to know which file is the one that needs to be parsed first
Thanks for your reply Frank.
Maybe I have missed something in the explanation you try, but I don't think it answers the "why" in my question (q1).
Maybe I should try to ask a different, but related, question focusing more on the encapsulation idea (or the "API of a bounded task-flow" if you will).
In this context it could help to think of a bounded task-flow as a (service) method-call, as some sometimes make a comparison saying "... The implementation of the task flow - like in Web Services - is a detail that only the developer of the task flow need to know ..." .
- (q2) Is it possible to create an ADF bounded task-flow that (catches and) handles every possible exception that is caused (thrown) in its own implementation? So, (catching and) handling all exceptions related to model, view, controller or whatever, "encapsulating" the exception aspect?
Frank Nimphius wrote:The question (q2) illustrates a potential real (and general) requirement.
... Not sure if there is a good solution to this or if there is a real requirement for it. ...
-  at Re: mutual dependent task-flows