Movatterモバイル変換
[0]ホーム
Unique ID numbers for compile/runtime error messages?
Eddie and Babskca17 at dial.pipex.com
Tue Apr 24 17:46:51 EDT 2001
No, you misunderstand me!The implementers don't have to document anything at all. They just have toadd a unique number to the end of every error message string that theinterpreter already generates as standard. Presumably, if the interpreterspews out "TypeError: call of non-function" then the message "call ofnon-function" is retrieved from the same string constant for each possiblecompilation scenario where this TypeError can occur (so if you change it to:"call of non-function (#123)" then the "123" will be displayed whenever thisstring constant is referenced). If the message doesn't come from the samestring constant each time then perhaps it would be a good idea if it did. Iapologise 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 todocument the error. The number merely allows the user to order notes moreeffectively.This does mean that all error message strings that exist in the standardPython interpreter have to be enumerated, but there is certainly no need tothink of and document every possible "meaning" of each error in advance(like knowing that some people are tripped up by case-sensitivity orwhatever; obviously there is no way the implementors could know all suchcontexts).I should add that I am aware that users can supply their own message stringsto exceptions that they raise in their own code. Obviously there is no waythat all of these can have their own ID number. I am just talking about thecommonly-occurring exceptions that can be raised by the interpreter. Thingslike:- 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'" shouldhave another and so on for each variable name!).needs-only-one-volunteer-if-concept-is-understood-ly y'rs,The terminally misunderstood,&.----------> 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>
More information about the Python-listmailing list
[8]ページ先頭