On 25 October 2011 22:13, John Toohey <[email protected]> wrote: > - Yes it quits, not aborts. The issue is that the WAListenerAdapter > throws ConnectionTimedOut exceptions, and in the headless state, these > un-handled exceptions cause the VM to shutdown. My Seaside app has a > custom Exception handler registered for the app, but its not called > here. > > This code is from the WAListenerAdapter, so all I want to do is catch > the exception and ignore it. Sockets timing out in a web app is not an > exception. The stack trace runs from the Socket class back to the > WAListenerAdapter class, so that is why I wanted to put a handler > there. The code is the original code from that class. > > In the context of my web app, a socket timing out is not exceptional, > so all I want to for the code to clean up after itself, and accept > back on the socket. I was hoping that the handler that I put it would > be sufficient, but your comments on the background process it making > me wonder. > >
Absolutely, WA..Adapter should handle such situations, or at least let user to handle them in a way he prefers to. But since this code related to Seaside, i guess you should open a discussion in seaside mailing list otherwise there are big chances that it will remain like today, because this code outside of pharo developers responsibility. -- Best regards, Igor Stasenko.
