On 11 October 2011 02:03, John Toohey <jt@parspro.com> 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 5:24 PM To: Pharo-project@lists.gforge.inria.fr 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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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.