Unique ID numbers for compile/runtime error messages? 
Author Message
 Unique ID numbers for compile/runtime error messages?

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?

&.



Sun, 12 Oct 2003 00:30:46 GMT  
 Unique ID numbers for compile/runtime error messages?


Quote:
> 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 seven{*filter*} 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



Sun, 12 Oct 2003 02:42:56 GMT  
 Unique ID numbers for compile/runtime error messages?
No, you misunderstand me!

The implementers don't have to document anything at all. They just have to
add a unique number to the end of every error message string that the
interpreter already generates as standard. Presumably, if the interpreter
spews out "TypeError: call of non-function" then the message "call of
non-function" is retrieved from the same string constant for each possible
compilation scenario where this TypeError can occur (so if you change it to:
"call of non-function (#123)" then the "123" will be displayed whenever this
string constant is referenced). If the message doesn't come from the same
string constant each time then perhaps it would be a good idea if it did. I
apologise if there is a good reason NOT to do this, but I don't see one.

It is the USER'S task to add whatever additional notes he/she needs to
document the error. The number merely allows the user to order notes more
effectively.

This does mean that all error message strings that exist in the standard
Python interpreter have to be enumerated, but there is certainly no need to
think of and document every possible "meaning" of each error in advance
(like knowing that some people are tripped up by case-sensitivity or
whatever; obviously there is no way the implementors could know all such
contexts).

I should add that I am aware that users can supply their own message strings
to exceptions that they raise in their own code. Obviously there is no way
that all of these can have their own ID number. I am just talking about the
commonly-occurring exceptions that can be raised by the interpreter. Things
like:-

         TypeError: call of non-function
         NameError: There is no variable named 'zoink'
         IndexError: string index out of range
         KeyError: twarg

(...and of course I am not saying that "There is no variable named 'zoink'"
should have one error number and "There is no variable named 'ftosk'" should
have another and so on for each variable name!).

needs-only-one-volunteer-if-concept-is-understood-ly y'rs,

The terminally misunderstood,
&.

----------

Quote:
> 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 seven{*filter*} 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



Sun, 12 Oct 2003 05:46:51 GMT  
 Unique ID numbers for compile/runtime error messages?
[Eddie and Babs]

Quote:
> Does anyone agree that it would be useful for each of Python's error
> messages to have its own unique ID number?

Yes.

*that*-was-easy<wink>-ly y'rs  - tim



Sun, 12 Oct 2003 08:20:56 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Unique Number or ID

2. Unique ID Number

3. Create unique ID from Employee Numbers

4. Print only messages with unique numbers

5. Clipper Runtime: DBCMD 2001 error message

6. Not found error message from LabVIEW runtime when called from VC++ with statically linked MFC

7. Runtime Unrecoverable Error Messages 416

8. Runtime Error Messages, HELP !!!

9. Runtime Error Message: Always Missing MxKRN23 in krn

10. runtime errors with lammpi compiled by intel compilers

11. Segmentation fault (Was: Runtime error in Forte compiled program)

12. Need to locate unique task ID in MVS

 

 
Powered by phpBB® Forum Software