-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IBX-8784: Added AbstractExceptionVisitor
template to allow fine-grained control of output
#128
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's an example response after the change?
No changes for the built-in exceptions. It's used as a template visitor for external packages to re-use code for error handling data shape. What I consider currently:
I'll provide a separate PR for relevant package in a few hours. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's an example response after the change?
No changes for the built-in exceptions. It's used as a template visitor for external packages to re-use code for error handling data shape.
What I consider currently:
- Extract parts of this class into an
abstract
template, and move it into Contracts- Current visitor design does not work for interfaces (only concrete classes) which limits external use a bit.
I'll provide a separate PR for relevant package in a few hours.
Ok. +1 for now. I think when I see usage it will be more clear to me. Do you think this approach should replace #63 or is it rather more about "how" to display specific exception instead of translating one exception into another?
This PR doesn't change anything related to REST / pure API object handling. As for the mapping provided by #63, I don't think it's the responsibility of the service that provides the response. As you noted, we have different practices within the same package. The only reason you provide this mapping is because there is a chance that REST endpoint will forget to map it itself. So I'd just put your solution as a separate event listener with higher priority. This way it would have a separate purpose and clean responsibility. |
getErrorMessage
and getErrorDescription
to Exception REST visitorAbstractExceptionVisitor
template to allow fine-grained control of output
Quality Gate passedIssues Measures |
Substantial changes to PR code
e7a32d0
to
2bc129a
Compare
…ion REST visitor
2bc129a
to
59e5424
Compare
Quality Gate passedIssues Measures |
Description:
This PR enables child Exception visitors to more easily control exception message and description presented by REST endpoints.
For QA:
Documentation: