[
https://issues.apache.org/jira/browse/SOLR-17549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18062267#comment-18062267
]
David Smiley commented on SOLR-17549:
-------------------------------------
I guess I lean to Option 2; I don't find it *that* hacky. Perhaps later option
1 could happen when we want to fight off NamedList more broadly for Solr 11.
> Reconsider error-handling in generated-v2 SolrResponses
> -------------------------------------------------------
>
> Key: SOLR-17549
> URL: https://issues.apache.org/jira/browse/SOLR-17549
> Project: Solr
> Issue Type: Bug
> Components: SolrJ, v2 API
> Affects Versions: 10.0
> Reporter: Jason Gerlowski
> Priority: Blocker
> Labels: V2
> Fix For: 10.1
>
>
> In most cases upon receiving an HTTP response, SolrClients will immediately
> parse it into a NamedList and then inspect that NamedList to see whether a
> client-side exception should be triggered.
> Our generated v2-API SolrRequest/SolrResponse classes work differently. They
> never convert the response into a NamedList, instead using Jackson to put it
> into a strongly-typed POJO. -Additionally, response parsing occurs lazily -
> typically not until after the SolrResponse has been returned to callers and
> they've invoked a special "getParsed()" method.-
> The combined effect of these two differences is that all of the
> error-detection/exception-throwing code in SolrClient is skipped when making
> generated-v2 requests! Callers can still detect errors by manually
> inspecting their response POJOs, but anyone expecting SolrJ's "no exception
> means success" convention are in for a frustrating shock.
> We should change how response-parsing happens in the generated-v2 case to
> match the rest of SolrJ. (Or alternately - investigate some more intuitive
> way to communicate failure.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
