[
https://issues.apache.org/jira/browse/GEODE-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444847#comment-16444847
]
John Blum commented on GEODE-2375:
----------------------------------
As a side note, I would argue that most (if not all) _Exceptions_ coming out of
Apache Geode should be _RuntimeExceptions_ anyway.
How should/would a user handle/recover from an Authentication failure (e.g. on
reconnect), or a No Subscriptions Servers Available Error/Exception, etc, in
code, at runtime?
Most of these type of problems require a configuration change and therefore
should lead to a RuntimeException and _fail-fast_ behavior.
If the internal Geode mechanisms (e.g. type system) detecting Exceptions in
order to induce a orderly shutdown along with properly cleaning up resources,
then I would suggest it be based on an Exception hierarchy defined by Geode
(rooted by a base Exception class, no less), and not whether the Exception is
checked or not.
As a general rule of thumb, users should not be forced to "catch" Exceptions
for which they cannot handle or recover from in their application code. That
is typically a design flaw.
> GemFireException should not inherit from RuntimeException
> ---------------------------------------------------------
>
> Key: GEODE-2375
> URL: https://issues.apache.org/jira/browse/GEODE-2375
> Project: Geode
> Issue Type: Improvement
> Components: core, general
> Reporter: Galen O'Sullivan
> Priority: Major
>
> {{GemFireException}} inherits from {{RuntimeException}}, which means that the
> majority of exceptions in Geode are unchecked. This means that we don't have
> the type system helping us to check potential failure conditions of our code,
> and it's not clear which functions may throw exceptions as a part of their
> nomal failure modes -- for example, {{ReplyException}} has a
> {{handleAsUnexpected}} method that seems to indicate that a normal
> {{ReplyException}} is not unexpected -- but that's not what the type
> inheritance says. {{GemFireException}} accounts for most of the exceptions in
> the codebase.
> Even if we were to convert most of the existing instances of
> {{GemFireException}} to {{GemFireRuntimeException}}, developers (especially
> new ones) would still be tempted to use {{GemFireException}} for new
> exceptions.
> Perhaps the best way to solve this (if we want all our exceptions to inherit
> from a central exception type, which I'm not entirely sold on) would be to
> create a new {{GeodeUncheckedException}} and {{GeodeCheckedException}}, and
> deprecate both kinds of {{GemFireException}}? Then we could convert old
> exceptions as time permits.
> There's a significant amount of work involved here whatever way we decide to
> change it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
