_Comment made by: alexmiller_
So, it's kind of interesting if you look into the details of this. Technically, at the point where the exception occurs, the defmulti is not on the stack (that's the dispatch function, which has already completed), but the defmethod is.
defmethods are actually defined as fn's and are typically treated as anonymous fns, although it's actually possible to name them independently:
user=> (defmulti dispatcher (fn [item] (:type item)))
#'user/dispatcher
user=> (defmethod dispatcher "cat" cat-method
[{:keys [lives]}]
(/ lives 0))
#object[clojure.lang.MultiFn 0x6e1d4137 "clojure.lang.MultiFn@6e1d4137"]
user=> (dispatcher {:type "cat" :lives 9})
ArithmeticException Divide by zero clojure.lang.Numbers.divide (Numbers.java:163)
user=> (pst *e 5)
ArithmeticException Divide by zero
clojure.lang.Numbers.divide (Numbers.java:163)
clojure.lang.Numbers.divide (Numbers.java:3813)
user/eval155/cat-method--157 (NO_SOURCE_FILE:11) ;; <== cat-method
clojure.lang.MultiFn.invoke (MultiFn.java:229)
user/eval161 (NO_SOURCE_FILE:12)
I think what would be best is if the defmethod function defaulted to a unique name based on the defmulti function name (if no name was specified).