Outlining the design patterns for customized exception and error messages #1264
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reasons for creating this PR
To outline and create better exception and error handling practices
Link to relevant issue(s), if any
#1250
(Error message leaks requested SPARQL endpoint host)
Description of the changes in this PR
The initial situation did not make it possible to easily create customized exception and error messages. At the moment many of the messages are hard coded and aim is to get rid of the hard coded messages.
This Draft Pull Request offers one alternative to improve the ways to customize exception and error handling or messages. It would be easy to use the static methods only for messaging or it is also possible to create instantiated classes for more dynamic error handling, depending on the needs.
Another option could be a separate key value based error message file to be referred to from the code but in that case there is no way to build any kind of customized logic to handle exceptions or errors.
Known problems or uncertainties in this PR
The PR needs more elaboration
Checklist