[
https://issues.apache.org/jira/browse/GEODE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham reassigned GEODE-7369:
-----------------------------------
Assignee: Bill Burcham
> Deprecate SystemFailure Class
> -----------------------------
>
> Key: GEODE-7369
> URL: https://issues.apache.org/jira/browse/GEODE-7369
> Project: Geode
> Issue Type: Bug
> Components: core
> Reporter: Bill Burcham
> Assignee: Bill Burcham
> Priority: Major
>
> The {{SystemFailure}} class is a clearing house for detecting and attempting
> to mitigate {{SystemFailure}} exceptions e.g. {{VirtualMachineError}} and
> {{OutOfMemoryError}}.
> This class should not exist. {{SystemFailure}} exceptions should be allowed
> to percolate up and cause the JVM to terminate as soon as possible with an
> informative message in the log, if possible.
> Here is what the JVM spec has to say [1]:
> "A Java Virtual Machine implementation throws an object that is an instance
> of a subclass of the class VirtualMethodError (sic) when an internal error or
> resource limitation prevents it from implementing the semantics described in
> this chapter. This specification cannot predict where internal errors or
> resource limitations may be encountered and does not mandate precisely when
> they can be reported."
> There's a typo in the spec there: it says "VirtualMethodError" when it means
> "VirtualMachineError". Anyhoo, the upshot is: the JVM spec does not apply
> after you've encountered a {{VirtualMachineError}}. As a result, there is no
> reason to believe that subsequent processing will make things _better_ (than
> exiting immediately).
> The SystemFailure class should be deprecated so no new dependencies to it are
> added. Existing dependencies on it, should be eliminated over time.
> [1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
