db3l.net at gmail.com
Thu Aug 30 00:33:09 CEST 2007
On 8/29/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> > If I
> > remember correctly the error mode is inherited, so an independent
> > small exec module could reset the mode, and execute the normal test
> > sequence as a child process.
> It would also be possible to put that into the interpreter itself,
> at least when running in debug mode.
Yep, although you might want to choose whether or not to do it in
interactive mode I suppose. Or, as in my subsequent message, it could
just be incorporated into the test runner (such as in regrtest.py).
> What does
> "Instead, the system sends the error to the calling process."
It's somewhat dependent on the type of problem that was going to lead
to the dialog box. For a catastrophic failure (e.g., GPF), such as
those that only provide OK (or perhaps Cancel for debug) in the
dialog, the process is still going to be abruptly terminated, as if OK
was pressed with no further execution of code within the process
itself. A parent process can detect this based on the exit code of
For other less critical failures (like the box that pops up when
trying to open a file on a removable device that isn't present), an
error is simply returned to the calling process as the result of the
original system call that triggered the failure - just like any other
failing I/O operation, and equivalent I believe to hitting Cancel on
the dialog that would otherwise have popped up.
More information about the Python-3000