Hello list,
I was thinking how I would control the opening of debugger on deployed application. Imagine I want to copy the stack and send it by email or something like that.
I could change the defaultAction of UnhandledError for example.
Now if I want to scope the control of popping debuggers I could use on:do: and I was wondering if there is an idiom. I was not sure that this is a good style to do on: UnhandledError do: .... but may be I'm wrong
So how do you do it.
Stef
We use Preferences>>disableProgrammerFacilities (modified in UI Enhancements to disable halos et., elsewhere modified to preserve cut/copy/paste shortcut keys).
Also sets the default ToolSet to nil meaning unhandled errors get handled by a popup dialog (though generally unsuccessful at resuming from there :-) ).
ToolSet might be the best place to start for you.
Regards, Gary.
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]On Behalf Of stephane ducasse Sent: 05 August 2008 5:32 PM To: The general-purpose Squeak developers list Subject: [squeak-dev] About controlling debugger popping up
Hello list,
I was thinking how I would control the opening of debugger on deployed application. Imagine I want to copy the stack and send it by email or something like that.
I could change the defaultAction of UnhandledError for example.
Now if I want to scope the control of popping debuggers I could use on:do: and I was wondering if there is an idiom. I was not sure that this is a good style to do on: UnhandledError do: .... but may be I'm wrong
So how do you do it.
Stef
In Qwaq Forums, we have a default error handler per-process which gets called if an error isn't handled directly. This makes it possible to attribute "other" processes with a viable error handler in particular if you expect this to be a potentially flaky subsystem (the finalization process has had that issue once upon a time).
In addition, we use a singleton (SystemErrorHandler default) which gets called if no per-process handler is installed (by default it dispatches to ToolSet default). The running application then installs itself as the default error handler and does whatever it wants with the resulting (unhandled) error.
The advantage is that a) you don't need to hack UnhandledError etc. for your specific application and b) that you can handle errors in *all* processes. Which obviously is a very helpful thing for a heavily multi-threaded application like Qwaq Forums ;-)
There are lots of other cool things we have done (if I may blatantly say so ;-) without "disabling programmer facilities" with the sledge hammer. For example, Qwaq Forums installs a custom user interrupt handler, so if you hit Alt-Period you are being asked for a password which allows you to do all sorts of fun things: From breaking into the sealed app, over enabling certain restricted features up to exposing additional developer options in menus for debugging the sealed application.
Needless to say, all of this is available in Croquet.
Cheers, - Andreas
stephane ducasse wrote:
Hello list,
I was thinking how I would control the opening of debugger on deployed application. Imagine I want to copy the stack and send it by email or something like that.
I could change the defaultAction of UnhandledError for example.
Now if I want to scope the control of popping debuggers I could use on:do: and I was wondering if there is an idiom. I was not sure that this is a good style to do on: UnhandledError do: .... but may be I'm wrong
So how do you do it.
Stef
In Sophie we do exactly that, we prompt the user for permission and ask for name-address-etc, plus any other additional information.
(a) many people give permission, we had to alter the stack trace-back logic to print lots more data btw. Perhaps as much as 200K of data has to come back in order to figure out why the walkback occured.
(b) No one ever supplies contact information, they will anonoymously beg for help tho. Sadly anonoymous pleas for help can't be answered
(c) That gets POSTed to a web site, where the server then saves and emails the Sophie Support Engineer. Obviously a bit of programming there could use a database to figure out if the error is unique or not etc. Even say to emailing the person back with a problem tracking number or existing entry
Hello list,
I was thinking how I would control the opening of debugger on deployed application. Imagine I want to copy the stack and send it by email or something like that.
Yup, same experience here. People are quite willing to tell you that your product sucks and breaks ;-) and we have taken great advantage of this. However, we don't ask for contact information; all you get is a "report error" button.
Cheers, - Andreas
John M McIntosh wrote:
In Sophie we do exactly that, we prompt the user for permission and ask for name-address-etc, plus any other additional information.
(a) many people give permission, we had to alter the stack trace-back logic to print lots more data btw. Perhaps as much as 200K of data has to come back in order to figure out why the walkback occured.
(b) No one ever supplies contact information, they will anonoymously beg for help tho. Sadly anonoymous pleas for help can't be answered
(c) That gets POSTed to a web site, where the server then saves and emails the Sophie Support Engineer. Obviously a bit of programming there could use a database to figure out if the error is unique or not etc. Even say to emailing the person back with a problem tracking number or existing entry
Hello list,
I was thinking how I would control the opening of debugger on deployed application. Imagine I want to copy the stack and send it by email or something like that.
Well people won't give you even an email address. This unfortunate breaks part of the problem question answer cycle. Although we might push all the stacks for all the processes and most of the data values, that sometimes only shows: Gee how did they do that, but then you have no way to ask what they were doing... Suggestions on how to entice that information out of a user is welcome.
Cheers,
- Andreas
John M McIntosh wrote:
In Sophie we do exactly that, we prompt the user for permission and ask for name-address-etc, plus any other additional information.
(a) many people give permission, we had to alter the stack trace-back logic to print lots more data btw. Perhaps as much as 200K of data has to come back in order to figure out why the walkback occured.
(b) No one ever supplies contact information, they will anonoymously beg for help tho. Sadly anonoymous pleas for help can't be answered
(c) That gets POSTed to a web site, where the server then saves and emails the Sophie Support Engineer. Obviously a bit of programming there could use a database to figure out if the error is unique or not etc. Even say to emailing the person back with a problem tracking number or existing entry
Hello list,
I was thinking how I would control the opening of debugger on deployed application. Imagine I want to copy the stack and send it by email or something like that.
Perhaps unhandled errors could be made more easily pluggable for deployment...
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]On Behalf Of John M McIntosh Sent: 05 August 2008 6:55 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] Re: About controlling debugger popping up
Well people won't give you even an email address. This unfortunate breaks part of the problem question answer cycle. Although we might push all the stacks for all the processes and most of the data values, that sometimes only shows: Gee how did they do that, but then you have no way to ask what they were doing... Suggestions on how to entice that information out of a user is welcome.
One thing you could do is to give people a ticket id (returned from the server) so they can check for themselves if they want to know if a problem was fixed. It doesn't require them to reveal any info but makes it possible to check for the status of the problem.
Also, I think the problem is merely one of convenience. If you would pre-populate the email they'd probably be fine with it. It's just that when people are frustrated (which they are since the system just blew up on 'em) they're usually not in the mood to spend more time than absolutely necessary. If it's one click, fine, if it's more, it's not.
Cheers, - Andreas
John M McIntosh wrote:
Well people won't give you even an email address. This unfortunate breaks part of the problem question answer cycle. Although we might push all the stacks for all the processes and most of the data values, that sometimes only shows: Gee how did they do that, but then you have no way to ask what they were doing... Suggestions on how to entice that information out of a user is welcome.
Cheers,
- Andreas
John M McIntosh wrote:
In Sophie we do exactly that, we prompt the user for permission and ask for name-address-etc, plus any other additional information.
(a) many people give permission, we had to alter the stack trace-back logic to print lots more data btw. Perhaps as much as 200K of data has to come back in order to figure out why the walkback occured.
(b) No one ever supplies contact information, they will anonoymously beg for help tho. Sadly anonoymous pleas for help can't be answered
(c) That gets POSTed to a web site, where the server then saves and emails the Sophie Support Engineer. Obviously a bit of programming there could use a database to figure out if the error is unique or not etc. Even say to emailing the person back with a problem tracking number or existing entry
Hello list,
I was thinking how I would control the opening of debugger on deployed application. Imagine I want to copy the stack and send it by email or something like that.
Hello John,
JMM> that sometimes only shows: Gee how did they do that, but then you have JMM> no way to ask what they were doing... Suggestions on how to entice JMM> that information out of a user is welcome. if they are willing to reply (our customers do) they won't remember how they did it. So we keep a list of the last 5000 function calls with parameters in memory and dump that list too.
Then in case of a crash we can follow the series of top level invocations. Did this when several customers reported the same bug and we couldn't reproduce it for months.
No Smalltalk so it was a lot of work :-))
Cheers
Herbert mailto:herbertkoenig@gmx.net
Herbert König wrote:
JMM> that sometimes only shows: Gee how did they do that, but then you have JMM> no way to ask what they were doing... Suggestions on how to entice JMM> that information out of a user is welcome. if they are willing to reply (our customers do) they won't remember how they did it. So we keep a list of the last 5000 function calls with parameters in memory and dump that list too.
What we do is writing log information to the transcript and send this along. It's an invaluable resource since you can basically follow along (in very general terms) what people were doing and in particular exceptional situations (for us that's mostly connection drops and reconnect handling) can be caught that way.
Cheers, - Andreas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Gary Chambers -
Herbert König -
John M McIntosh -
stephane ducasse