|
Reason: MoaZSException (and: its builder) were used to collect
intermediary results while stepping through the delivery request
backend. These results were needed to generate meaningful responses
towards the sender application in case of error. However, the builder
sprawled over too many interfaces (e.g. DeliveryRequestBackend and
TNVZHelper) and it became difficult to understand from where
intermediary results originated.
Solution: Put MoaZSException on diet:
- Remove all DeliveryAnswer fields from MoaZSException and refactor
code base to ensure that the removed fields get sourced by other
means.
- Remove Builder since amount of parameters is manageable.
Refactor DeliveryRequestBackend:
- Instead of passing down the builder and using MoaZSException as the
only source for intermediary results, we collect available results
at the outermost stack frame (DeliveryRequestBackend.accept) and
only retrieve results via exception if those results appear
somewhere down the stack frame (E.g. PredviceNoteSent). We collect
available results with the "fallbackAnswerBuilder" and switch to the
msg client response, once received.
Refactor MsgResponseBackend:
- Handle cases (response missing, binary response missing) properly.
- Integrate changes from MsgResponse.generateError()
Refactor TVNZHelper:
- Remove MoaZSExceptionBuilder from all interfaces.
Refactor MsgResponse.generateError:
- Change interface such that it's more intuitive.
- Implement NotificationResponse.generateError.
- Implement RequestStatusResponse.generateError.
Others:
- Replace all invocations against MoaZSException.Builder.
|
