[
https://issues.apache.org/jira/browse/GEODE-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864127#comment-15864127
]
Darrel Schneider commented on GEODE-2375:
-----------------------------------------
Something that might work, and not break old code, is to introduce a new
abstract subclass of GemFireException called GeodeRuntimeException. We would
deprecate GemFireException saying to instead use GeodeRuntimeException. Any of
our current instances of GemFireException would be changed to instead subclass
GeodeRuntimeException. Old code that catches GemFireException or does
instanceof checks would continue to work. We would need to confirm that if we
java serialize an instance of one of the exception that used to subclass
GemFireException but now subclass GeodeRuntimeException would still deserialize
in an old client that does not have GeodeRuntimeException on its classpath.
We would do all of the above with GemFireCheckedException except its new
abstract subclass would be GeodeException.
> GemFireException should not inherit from RuntimeException
> ---------------------------------------------------------
>
> Key: GEODE-2375
> URL: https://issues.apache.org/jira/browse/GEODE-2375
> Project: Geode
> Issue Type: Bug
> Components: core, general
> Reporter: Galen O'Sullivan
>
> {{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
(v6.3.15#6346)
