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

---

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.