On 4/25/2012 3:27 PM, Bryce Boe wrote:
Hi,
I looked through the man page for python's interpreter and appears that there is no way to properly distinguish between error messages output to stderr by the interpreter and output produced the by a user-program to stderr.
That should be a false distinction. User programs should only print error messages to stderr. Some modify error messages before they get printed. Some raise exceptions themselves with messages. The interpreter makes makes no distinction between user code, 3rd party code, and stdlib code.
What I would really like to have are two things:
1) an option to output interpreter generated messages to a specified file, whether these messages are uncatchable syntax errors, or catchable runtime errors that result in the termination of the interpreter. This feature would allow a wrapper program to distinguish between user-output and python interpreter output.
'Raw' interpreter error messages start with 'SyntaxError' or 'Traceback'. Runtime errors do not seem to go to the normal stderr channel.
2) an option to provide a structured error output in some common easy-to-parse and extendable format that can be used to associate the file, line number, error type/number in some post-processing error handler. This feature would make the parsing of error messages more deterministic, and would be of significant benefit if other compilers/interpreters also provide the same functionality in the same common format.
Exception instances have a .__traceback__ instance that is used to print the default traceback message. So it has or can generate much of what you request. I believe traceback objects are documented somewhere. Some apps wrap everything in try: run_app except Exception as e: custom_handle(e) -- Terry Jan Reedy