On Jan 20, 2008 1:34 AM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote:
> On Sat, 2008-01-19 at 16:12 -0600, Patrick R. Michaud wrote: > > On Fri, Jan 18, 2008 at 09:41:01PM -0800, Geoffrey Broadwell wrote: > > > "Null PMC access in invoke(); misspelled sub name in function call?" > > > > I fear this error message may actually send a beginner down a false > > trail. This particular error occurs anytime we attempt to call > > a sub that cannot be located in the current lexical/namespace/global > > symbol table. So, there could be other causes for the error besides > > a simple misspelling. > > Fair enough. I had indeed experienced the error both in the direct code > I presented in the initial ticket, and in the case of a symbol table > lookup. But no matter what route I took to get there, there were only > two mistakes I had made: either I had misspelled the name somewhere, or > I hadn't inserted it into the symbol table before looking it up (which > itself had a few different causes -- one time it even turned out to be > saving one file but not another in my editor). > > > The "Null PMC access in invoke()" except gets thrown at the > > point of the invokecc call, at which point we no longer have > > convenient access to the name. > > Nodnod, understood. > > > So, the options I see at this point are to modify the find_name > > opcode to throw an exception when asked to locate a non-existent > > symbol (note that this is somewhat counter to the way we've been > > heading), or to have the PIR compiler generate code to check > > the result of find_name and throw an exception. > > I personally don't want any runtime cost to improve this error message; > I was merely suggesting the first thing that came to mind to demystify > the original message. Heck, we can put a whole paragraph in the error > message if need be, but *no runtime cost for correct code* please. I'd > rather have a bad error message than a slower VM. > > It might not be a bad idea to create some kind of glossary of error messages from the PIR compiler. So, some kind of overview, "if you get *this* error message, you might want to check this, that and such". Maybe an additional error code, so it can be an indexed list. Of course, this list should evolve over time, as it's difficult to create it completely from scratch. (Also, IMCC could use some cleanups anyway somewhere in the future in this field and others.. for instance, there are some mallocs that aren't checked for success. I assume this is not really desirable for a production system that runs a 100K business) kjs
