A full-blown OutOfMemoryException (or, as we like to call it, an "OOM") can only be handled by either coding the application to ensure it doesn't run away with memory allocation requests or by expanding the memory allocated at startup to the JVM (the -Xmx parameter on the "java" command). Any attempt to catch and handle an OOM will probably fail because the exception handler itself will probably end up trying to allocate memory to handle the exception. Plus since an OOM can happen at random places, there's not much you can safely do to repair things. So an OOM normally just bounces up and out of the application to the core JVM which gives up and terminates.
I can't speak for MQ, but in the
Tomcat server, resources that might run out of buffers are tuneable and usually have a defined upper limit. When the upper limit is exceeded, Tomcat will simply stop accepting new requests until there are free resources available. So there's no OOM, since no attempt is made to allocate more buffers. Unless, of course, the Tomcat JVM's mx setting was too low to allow for the maximum number of buffers.
This is very definitely something that you can expect to be settable in different ways depending on which server product you are using. So I'd check the documentation for your MQ server.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.