"m.u.k" <[EMAIL PROTECTED]> wrote: > > Hi, > > Guido van Rossum <[EMAIL PROTECTED]> wrote in > news:[EMAIL PROTECTED]: > > > Your efforts would be better directed towards fixing the causes of the > > fatal errors. > > > > I see no need to hook Py_FatalError, but since it's open source, you > > are of course free to patch your own copy if your urge is truly > > irresistible. Or I guess you could run Python under supervision of gdb > > and trap it that way. > > Well, I admit it is a bit triva(as its implementation), at least nobody > wanted it within Python's 10+ lifetime. Indeed Im using my own patched copy, > I just thought it'd be good some other naughty boy playing dangerous games > with interpreter internals not spend hours in debugger trying to reproduce > the crash. > > > But tell me, what do you want the process to do instead of > > terminating? Py_FatalError is used in situations where raising an > > exception is impossible or would do more harm than good. > > The need for this is only logging purposes. eg the process just terminates > on client machine, you have no logs, no clues(except a coredump), nightmare!. > Some sort of log would be invaluable here.
Offering any hook for Py_FatalError may not even be enough, as some of those errors are caused by insufficient memory. What if a hook were available, but it couldn't be called because there wasn't enough memory? Of course there is the option of pre-allocating a few kilobytes, then just before one calls the hook, freeing that memory so that the hook can execute (assuming the hook is small enough). I'm not sure if this is a desireable general mechanic, but it may be sufficient for you. If you do figure out a logging mechanism that is almost guaranteed to execute on FatalError, post it to sourceforge. - Josiah _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
