Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>In general, it is a bad idea to try to catch and recover from an OOM.</p> <ol> <li><p>An OOME could also have been thrown on other threads, including threads that your application doesn't even know about. Any such threads will now be dead, and anything that was waiting on a notify could be stuck for ever. In short, your app could be terminally broken.</p></li> <li><p>Even if you do successfully recover, your JVM may still be suffering from heap starvation and your application will perform abysmally as a result.</p></li> </ol> <p>The best thing to do with an OOME is to let the JVM die. </p> <p>(This assumes that the JVM <em>does</em> die. For instance OOMs on a Tomcat servlet thread do not kill the JVM, and this leads to the Tomcat going into a catatonic state where it won't respond to any requests ... not even requests to restart.)</p> <p><strong>EDIT</strong> </p> <p>I am not saying that it is a bad idea to catch OOM at all. The problems arise when you then attempt to recover from the OOME, either deliberately or by oversight. Whenever you catch an OOM (directly, or as a subtype of Error or Throwable) you should either rethrow it, or arrange that the application / JVM exits.</p> <p>Aside: This suggests that for maximum robustness in the face of OOMs an application should use <a href="http://java.sun.com/javase/6/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler)" rel="noreferrer">Thread.setDefaultUncaughtExceptionHandler()</a> to set a handler that will cause the application to exit in the event of an OOME, no matter what thread the OOME is thrown on. I'd be interested in opinions on this ...</p> <p>The only other scenario is when you know <em>for sure</em> that the OOM has not resulted in any collateral damage; i.e. you know:</p> <ul> <li>what specifically caused the OOME,</li> <li>what the application was doing at the time, and that it is OK to simply discard that computation, and</li> <li>that a (roughly) simultaneous OOME cannot have occurred on another thread.</li> </ul> <p>There are applications where it is possible to know these things, but for most applications you cannot know for sure that continuation after an OOME is safe. Even if it empirically "works" when you try it. </p> <p>(The problem is that it a formal proof is required to show that the consequences of "anticipated" OOMEs are safe, and that "unanticipated" OOME's cannot occur within the control of a try/catch OOME.)</p>
    singulars
    1. This table or related slice is empty.
    1. POCatching java.lang.OutOfMemoryError?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USStephen C
    1. USStephen C
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COYes, I agree with you. In general, it is bad idea. But why then I have possibility to catch it? :)
      singulars
      1. PO
      1. USDenis Bazhenov
    2. CO@dotsid - 1) because there are cases where you should catch it, and 2) because making it impossible to catch OOM would have negative impact on the language and/or other parts of the Java runtime.
      singulars
      1. PO
      1. USStephen C
    3. COYou say: "because there are cases where you should catch it". So this was part of my original question. *What* are the cases when you want to catch OOME?
      singulars
      1. PO
      1. USDenis Bazhenov
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload