[Python-ideas] Structured Error Output

[Mike Meyer]

On Wed, 25 Apr 2012 15:06:16 -0700
Bryce Boe <bboe at cs.ucsb.edu> wrote:

> Perhaps I wasn't very clear. I want to write a tool to collect error
> messages when I run a program. Ideally the tool should be agnostic to
> what language is used and should be able to identify syntax errors,
> parser errors, and runtime errors. While I can parse both the stdout
> and stderr streams to find this information, from what I can tell
> there is no way to distinguish between a real syntax error (output to
> stderr):
> 
>   File "./test.py", line 5
>     class
>         ^
> SyntaxError: invalid syntax
> 
> and a program that outputs that exact output to stderr and exits with status 1.

Correct. And it isn't a problem, because it shouldn't matter if the
programmer wrote a bit of code that caused the compiler to raise a
syntax error, raised the syntax error themselves, evaled a string that
raised the syntax error, or wrote the message explicitly to standard
error: all those cases represent a syntax error to the programmer.

> This "channel" sharing of control (error messages) and data is a
> problem that affects more than just the python interpreter. I am
> hoping to start with python and provide a way to separate the control
> and data information so I can be certain that output on the "control"
> file descriptor is guaranteed to be generated by the interpreter.

If your program is writing *data* to stderr, it's badly designed. You
should fix it instead of trying to get Python changed to accommodate
it.

Or maybe you're trying to draw a distinction between messages
purposely generated by the programmer, and messages the programmer
didn't want? I think that's an artificial distinction. An error is an
error is an error, and by any other name would be just as
smelly. Whether it's an exception raised by the interpreter, an
exception raised by the programmer, or just a message printed by the
programmer really doesn't matter.

Python programmers have complete control over all of this, and can
make it do what they want. Trying to make distinctions based on
default behaviors is misguided.

        <mike

-- Mike Meyer <mwm at mired.org> http://www.mired.org/ Independent
Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org