[Python-ideas] Structured Error Output

Terry Reedy tjreedy at udel.edu
Wed Apr 25 23:33:21 CEST 2012


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




More information about the Python-ideas mailing list