On 11 October 2011 00:24, John Toohey <[email protected]> wrote: > The exception is not coming from my code, if it was I could trap it. > Regardless, isn't shutting the VM down a bit of overkill in this case? >
No, it is not. For handling an unhandled exception, without knowing its source and cause which led to it, i don't see any other alternative. In headless mode there is no user who could respond to unhandled exception popups, therefore if your software doesn't handles it by itself, by default an image just quits to OS. > On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <[email protected]> wrote: >> On 10 October 2011 23:19, John Toohey <[email protected]> wrote: >>> Hi, >>> >>> I've had a problem since 1.0 with socket timeouts throwing exceptions >>> and invoking the debugger in my headless images. I don't know why a >>> socket timeout is considered exceptional, but I've gotten used to >>> using VNC to log into the server and close the debuger windows. >>> However, I've moved to COG and the latest one-click images, and now >>> the error terminates the VM. >>> >>> My app is a standard Seaside server, using the streaming connector for >>> Comet support. >>> >>> I've attached the PharoDebug.log. It would be appreciated if anyone >>> could help me with this problem, as I'm at a loss where to even begin. >>> >> >> So, just put an exception handler, and handle this exception in a >> manner you want >> and then your image will keep working! :) >> >>> >>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu) >>> >>> >>> -- >>> ~JT >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > > -- > ~JT > > -- Best regards, Igor Stasenko.
