[Pyobjc-dev] Debugging hooks and signal handlers
Brought to you by:
ronaldoussoren
From: Bob I. <bo...@re...> - 2004-04-01 20:44:03
|
I've added support for CFRunLoop (NSRunLoop) signal handling via Mach ports. This means that Ctrl-C (from a controlling terminal) will actually do something useful. If there is an NSApplication instance, it will send it a terminate: message, otherwise it will os._exit(1). This functionality is automatically enabled if you use PyObjCTools.AppHelper.runEventLoop(...) or the new runConsoleEventLoop(...) (uses NSRunLoop instead of NSApplication). It also means that more obscure uses of signals (handling of SIGHUP, etc.) can be done.. but you're on your own there. I have not documented any of it, but PyObjCTools.MachSignals sports essentially the same interface as the signal module. You shouldn't need to know about the implementation of the _machsignals module. Additionally, I've wrapped the ExceptionHandling framework to allow debugging of stuff easier. The only hooks you should need to use for this is the PyObjCTools.Debugging module and one of the following functions: installPythonExceptionHandler() (logs tracebacks for any python exception that crosses the PyObjC bridge) installVerboseExceptionHandler() (logs tracebacks and ObjC stack traces for any ObjC exception raised) I've done some experiments, and it doesn't seem to be useful to handle uncaught exceptions. If it were, I would add the functionality to AppHelper. From what I understand, NSRunLoop, NSTimer, etc. are going to catch exceptions and throw them away, and anything else should be automatically converted and raised as a Python exception. So essentially, if you come up with an exception that you are unsure of, and aren't ready to gdb it, then call one of the aforementioned functions before the exception is expected to occur (probably before you start your runloop). Somebody please feel free to go over these new modules and properly document them, patches/commits welcome :) -bob |