| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
With this approach, the Problem Details response will not be parsed from the Access Grant service for instance. Is it something we want to add in a subsequent PR, or are we choosing not to support this for the time being? |
Sorry, something went wrong.
What I would suggest is that we make the ProblemDetails class into an interface, placing it in the API module. Then, there can be implementations in the solid module (as in this PR) and also in other modules, as needed |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This is an alternative to #1248
In conversation with @langsamu, we discussed how throwing an exception in the low-level client conflicts with the overall architecture of the JCL, and making that work (as in #1248) adds a lot of complexity to the very core of the client processing, which is the last place we want to add complexity.
This PR takes an alternative approach: here, any ProblemDetails structures exist only in the high-level (solid) client, which is the only place where exceptions get thrown.
This also means that the previously existing ofModel, etc, in the Jena and RDF4J modules are brought back to their original (non-deprecated) state.
In terms of commits, this reverts #1159, #1162 and #1184. The fourth commit reworks the implementation of ProblemDetails by relocating it to the solid module.