Re: no-applicable-method

[kempf@Sun.COM]

Gregor writes:
>>I don't believe this is appropriate, because call-next-method itself
>>isn't doing any method lookup.  Another way of saying this is that
>>call-next-method is not a generic-function that is failing to find an
>>applicable method.''

RPG writes
>>I think his reasoning is not correct and suffers from making distinctions
>>that aren't important. What does CALL-NEXT-METHOD do? Assume we are
>>talking about primary methods. There is a set of applicable methods
>>that are ordered from most specific to least specific. If call-next-method
>>is invoked, the next most specific applicable method is invoked. If there
>>is none, then there is no less specific applicable method.

Danny writes:
>>I think the critical issue here is that for intelligent error handling,
>>different arguments are necessary for NO-NEXT-METHOD and NO-APPLICABLE-METHOD.
>>NO-APPLICABLE-METHOD only needs the generic function and the arguments.
>>NO-NEXT-METHOD also needs the method that contained the call to
>>CALL-NEXT-METHOD. Hence, these two need to be different functions. 

Gregor writes:
>>In addition, it won't be possible for users to further specialize this
>>case of no-applicable-method.  The only possible specializations are
>>function and (eql #'call-next-method).  With no-next-method, the user
>>can do something like:

There are two answers to this question, a short one and a longer one.
The short one is that anyone doing development is probably going to
look at a stack backtrace to find out where the error occured anyway,
so the originating method should be available from that.

However, Gregor has made a good point, in that specializations on 
no-applicable-method would be difficult, which leads to the 
longer answer. The problem there is that the parameter specializers 
in my original proposal were not correct. The actual method definition 
should look like:


(defmethod no-applicable-method ((method standard-method) &rest arguments)

  (error "No applicable method for CALL-NEXT-METHOD from method ~S having~
	  argument list ~S.~%" method arguments)
)

This would allow message forwarding, specialization for custom methods, etc.
If, for some reason, the generic function is of interest in an error
report, then it can be obtained by using the reader operation 
(method-generic-function) on the method. If, for some reason, someone
wants to customize so that forwarding or the error message depends on
both the generic function and the method, they can write an additional
method which does the forwarding or error message, and call it from
no-applicable-method:

(defmethod no-applicable-method ((method my-method) &rest arguments)

  (apply #'my-no-matching-method method (my-method-generic-function) arguments)
)

In the case of standard-generic-function and standard-method, enough
information in the error report can be obtained from the method object
where the call originated and the arguments to the call.

The semantics of no-applicable-method would seem to be general enough to
cover no next method as a special case.