[PROPOSED PATCH] Improving the "Sub Not Found" Error Message
Chromatic
unhelpful error message "Null PMC access in invoke()". Sometimes you can
figure out what's wrong given the backtrace. Often you can't.
It would be nice instead to get a more specific error message indicating that
you tried to invoke a sub that doesn't exist.
There are a couple of ways to do this.
fixup_globals() in compilers/imcc/pbc.c runs at the end of emitting a PBC
segment. It converts all of the symbolic (named) lookups of subs into direct
lookups, where Parrot already knows about subs of the appropriate name. It
translates the remaining lookups into find_name ops.
The right approach is probably to modify this code to add a check for PMCNULL
for the returned PMC and throw an exception in that case. However, because
this fixup runs at the end of the PBC process, it's really difficult to
splice in multiple ops, especially when they need to keep around the string
constant or register containing the symbol for dynamic lookup.
This may be fixable when we have PBC PMCs.
The attached patch -- for discussion only -- adds an experimental op which
performs the lookup and throws an exception if the sub is PMCNULL. Nothing
else uses this op, and it doesn't perturb the existing find_name op, which is
important.
If the op goes away in the future or if there's an easier way to emit this
error message, that's fine, but I do suggest that adding this error message
improves debuggability.
All tests still pass; this feature obviously needs tests.
-- c
Patrick R. Michaud
> When you try to invoke a sub that doesn't exist, Parrot currently gives the
> unhelpful error message "Null PMC access in invoke()". Sometimes you can
> figure out what's wrong given the backtrace. Often you can't.
Just a quick note here to link this thread to RT#49972, which
has a similar discussion.
> ...
> The attached patch -- for discussion only -- adds an experimental op which
> performs the lookup and throws an exception if the sub is PMCNULL. Nothing
> else uses this op, and it doesn't perturb the existing find_name op, which is
> important.
>
> If the op goes away in the future or if there's an easier way to emit this
> error message, that's fine, but I do suggest that adding this error message
> improves debuggability.
+1 on all counts. This is extremely important for debugging programs
written in HLLs. Important enough, in fact, that I was going to
modify PCT so that the code it generates for subroutine calls
would also check for null subs and throw an exception if they don't
exist. But I think having Parrot do this automatically is superior
to trying to handle it in generated code -- even though it means
adding a special "find_name_not_null" opcode.
I'd like to see this patch or something like it applied relatively
soon. If it's not likely to happen within the next week or so, then
I'll go ahead with my plan to resolve the issue from within PCT until
Parrot does have a good solution.
Thanks!
Pm
Patrick R. Michaud
> > When you try to invoke a sub that doesn't exist, Parrot currently gives the
> > unhelpful error message "Null PMC access in invoke()". Sometimes you can
> > figure out what's wrong given the backtrace. Often you can't.
> > The attached patch -- for discussion only -- adds an experimental op which
> > performs the lookup and throws an exception if the sub is PMCNULL. Nothing
> > else uses this op, and it doesn't perturb the existing find_name op, which is
> > important.
>
> soon. If it's not likely to happen within the next week or so, then
> I'll go ahead with my plan to resolve the issue from within PCT until
> Parrot does have a good solution.
The PCT-based solution is now implemented in r27351. In particular,
when running a PCT-based language such as NQP or Rakudo (perl6),
a statement like
foo(1);
now throws an exception saying "Cannot invoke non-existent sub 'foo'"
instead of "Null PMC in invoke".
Pm