Unique ID numbers for compile/runtime error messages?

[Steve Holden]

"Eddie and Babs" <kca17 at dial.pipex.com> wrote in message
news:3ae5abba$0$15030$cc9e4d1f at news.dial.pipex.com...
> Does anyone agree that it would be useful for each of Python's error
> messages to have its own unique ID number?
>
> The use of this is mainly to make it easy to look up additional
descriptions
> and personal notes relating to the error messages. For example, the
> {Python}/Misc/cheatsheet document contains in its "Idioms and hints"
> section:-
>
>      "TypeError: call of non-function" often means a list missing a comma
>
>
>
> There must be many similar examples. We all have such pieces of wisdom
about
> what errors actually "mean" in our heads, but it is difficult to write
them
> down and they are difficult to share with others. It is probably not a
good
> idea to try to build such descriptions into the error messages themselves,
> as they often have relevance only in certain contexts and to certain
people
> (eg, some people are prone to missing out commas, others are not; name
> errors may happen to students because they miss out quotes, but happen to
> former Pascal programmers because they aren't used to case-sensitivity).
>
> What I am suggesting is that each Python error message string be given a
> unique number. Then, when the error occurs, the error number could be
> appended to the message, preferably in a fixed format (three digits with
> leading zeros, say). So we might have:-
>
>     TypeError: call of non-function (#025)
>
> ...indicating that this was error message number 025. The poor victim of
> this error could then look up its description by the number. This is much
> easier than trying to find the raw message text in a list. It would be
> straightforward, say, to include an ordered list of error messages and
> common solutions/meanings at the back of a set of class notes for
students.
> And it would also be easy to write a program to look up the fixed format
> number in a database and display a description along with a user's own
> additional notes. It might even be possible to redirect "stderr" to an
> object which retrieves the expanded error description automatically, or
> records statistics about how frequently each error type occurs, etc.
>
>
> What do you all think?
>
Sort of like my favorite PL/1 F-level compiler message:

    IEB042I: Impossible happened

(I've probably not used the actual number) When you looked up IEB042I in the
IBM OS/360 Handbook of Error Messages (such a document existed, but was
probably called something even more turgid), it effectively told you this
was a compiler error which the designers wanted to know about. I remember
happily a visit from the IBM Systems Engineer (or was it the Customer
Engineer?) at which we produced about seventeen programs which had elicited
this message during the previous three months.

Of course the real problem is that these error messages are simply responses
to exceptions. Assuming the real exception is correclty reported, (such as
TypeError above) this still leaves a good deal of leeway in explaining the
problem. Do we expect the implementers to document *every* possible reason
why a particular syntax error exception might be raised during compilation?

Or do you want a Python Handbook of Error Messages?

needs-an-army-of-volunteers-ly y'rs  - stevE