[ https://jira.jboss.org/jira/browse/JBREM-1183?page=com.atlassian.jira.plu... ] David Lloyd commented on JBREM-1183: ------------------------------------ The safest way to ensure that a resource is reclaimed in the event of an exception is to use something like this: boolean ok = false; try { ...do sensitive operations... ok = true; } finally { if (! ok) { safeClose(resource); } } where "safeClose" is a method which surrounds the appropriate cleanup task (close in this case) with a try/catch (Throwable t) which logs t (it's never a good idea to allow exceptions to be propagated from a finally block). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBREM-1183?page=com.atlassian.jira.plu... ] Ron Sigal commented on JBREM-1183: ---------------------------------- org.jboss.remoting.transport.socket.ServerThread.doRun() now handles java.lang.Error's by catching and logging them and continuing to run. The reason for continuing to run is that, unlike, say, SocketException, an Error does not necessarily imply that the connection is unusable. Rather, it's possible that the Error was specific to a particular application and that another application could still use the connection successfully. The change has been applied to branches 2.2 and 2.x. Unit tests: org.jboss.test.remoting.transport.socket.ErrorTestCase. Waiting for hudson results. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira