[
https://issues.apache.org/jira/browse/CURATOR-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165396#comment-14165396
]
John Marsten commented on CURATOR-135:
--------------------------------------
I strongly favor switching to the more fine-grained approach suggested in this
issue.
Java's linguistic treatment of checked exceptions is frequently cited as one of
its largest design flaws. But the concept of categorizing exceptions into
expected and unexpected is sound, and particularly important in an IO-intensive
framework like Curator. Universally throwing Exception gives callers no
information about which error conditions are recoverable or retryable and which
error conditions resulted from programming error and leave the system in a
corrupt state.
And callers can't just "do nothing" if they want to prevent the universal
Exception pattern from leaking into the application code. Currently, developers
using Curator have to do something like the suggested "scrub" for every Curator
call they make. So multiply this error-prone effort times the number of Curator
calls made in the application... and times the number of applications using
Curator.
Checked exceptions are commonly criticized, yet the technique of universally
throwing Exception is unique among Java libraries I have seen. It is possible
that Curator is advancing the state of the art in Java design patterns. But it
is more likely that the techinique is questionable and has been rejected by
most API developers.
Changing the universal Exception pattern will be labor-intensive for Curator
developers--and for all Curator users, because this would be a breaking change.
But in my opionion, the usability improvement would be worth it.
> API Cleanup: Avoid throwing Exception
> -------------------------------------
>
> Key: CURATOR-135
> URL: https://issues.apache.org/jira/browse/CURATOR-135
> Project: Apache Curator
> Issue Type: Improvement
> Reporter: Mike Drob
> Assignee: Jordan Zimmerman
>
> It would be nice if the API did not throw Exception in so many places and
> threw the more specific subclasses instead. We should scrub the API to
> improve the method signatures, possibly creating sub-tasks to do so on a
> module-by-module (or more granular) basis.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
