[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