[
https://issues.apache.org/jira/browse/SOLR-18236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18079894#comment-18079894
]
Jan Høydahl commented on SOLR-18236:
------------------------------------
Have always thought solrj exceptions were confusing, this sounds like a good
plan. I'd reserve the breaking stuff for 11.0 (main)
> SolrJ exception hiearchy needs work
> -----------------------------------
>
> Key: SOLR-18236
> URL: https://issues.apache.org/jira/browse/SOLR-18236
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: David Smiley
> Priority: Major
>
> +SolrClient.request()+ declares +throws SolrServerException, IOException+
> with javadoc claiming:
> * *IOException* — "communication error with the server"
> * *SolrServerException* — "error on the server"
> Reality is the inverse on both axes:
> ||Scenario||Actual exception||Checked?||
> |Server returns non-2xx|RemoteSolrException (extends SolrException →
> RuntimeException)|*unchecked*|
> |Response body read fails (true I/O error)|RemoteSolrException|*unchecked*|
> |Server timeout / connection refused|SolrServerException (wraps the
> IOException)|checked|
> |No live servers / retries exhausted|SolrServerException|checked|
> |Raw IOException propagated as-is|almost never|—|
> h3. Contradictions
> # "Error on the server" (4xx/5xx reply) surfaces as *unchecked*
> RemoteSolrException — the javadoc says it should be SolrServerException.
> Compiler cannot help callers handle the most common failure mode.
> # "Communication error" rarely surfaces as IOException. Every concrete
> SolrClient wraps IOException (ConnectException, socket timeout, etc.) into
> SolrServerException. The +throws IOException+ clause is essentially dead.
> # HttpSolrClientBase.processErrorsAndResponse catches a real I/O error
> reading the response body and re-throws it as RemoteSolrException — calling a
> transport failure a "remote error."
> # 52 call sites just do +catch (SolrServerException | IOException e)+ and
> treat them identically — the split has no observable value at most call sites.
> # Yet 45 sites specifically catch RemoteSolrException to inspect +e.code()+
> — the HTTP-status-bearing exception is the genuinely useful concept, and it
> is the one the type system hides.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
