[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
>>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
>>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.
>>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.
>>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
(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.