Earlier quoted context omitted.
> difficulty of correctly recovering from an OOM exception is between hard and impossible. In Java out of memory is signaled with an OutOfMemoryError which is a throwable (and can be caught) but is not technically an exception. Errors should generally never be caught and cannot be recovered from, which is how they differ from exceptions.
It's not great, but you can always catch and retry if your belief is that the GC will free enough memory to allow the attempt to continue after the memory pressure subsides. Let's say you get 1/100 requests that are randomly sent to your process. That 1 takes 100x the average memory usage of the others. You could spin it out to different services to better handle the weird one-off, but that doesn't always make sense.…
No, you cannot. Catching, for example, StackOverflowError (which inherits from Error) can lead to very strange deadlocks and such (if locking is relying on try-finally discipline, as it should), even if you do "almost nothing" before re-throwing.
It's a huge hornet's nest of weirdness to even attempt to catch anything which derives directly from Error. (Rather than RuntimeException/Exception.)
EDIT: There are some really strange subclasses of Error now that I think about it. E.g. VirtualMachineError ... I don't think I've ever seen that in any logs, thankfully, but what exactly is the program (running on the failing VM) supposed to do if that is thrown? It'd be like trying to carry on or log an error if suddenly 1==2 turned out to be true.