On 11 October 2011 02:03, John Toohey <[email protected]> wrote: > Yep, now even if I fix this, I'll have to move each of my apps to a > separate VM. Dynamic typing and Web apps are not always a perfect > match, and I don't want an error in one bringing everything down. > > I'm guessing that this was not a problem for me before, as the older > images or the squeak VM started the UIManager even in headless mode. > Therefore when I used VNC to check the servers, I would see the > debugger windows. > You could hack the UnhandledError default action to suit your needs.
There's many ways to force system to behave like you want. > > On Mon, Oct 10, 2011 at 18:27, Schwab,Wilhelm K <[email protected]> wrote: >> John, >> >> No question, the punishment certainly exceeds the crime :) I was making a >> general plea for what I really believe is the correct way to build network >> software. >> >> Bill >> >> >> >> >> ________________________________________ >> From: [email protected] >> [[email protected]] On Behalf Of John Toohey >> [[email protected]] >> Sent: Monday, October 10, 2011 5:24 PM >> To: [email protected] >> Subject: Re: [Pharo-project] Socket timeout terminates COG VM >> >> 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? >> >> 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 >> >> >> > > > > -- > ~JT > > -- Best regards, Igor Stasenko.
