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
Locked
