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