[slime-devel] Error signalling and handling in DEFINTERFACE methods?
Peter Seibel
peter at gigamonkeys.com
Sun Mar 5 18:17:03 UTC 2006
After being bit for about the billionth time by trying to ,cd to a
file rather than a directory with the result of leaving
*default-pathname-defaults* set to something that doesn't merge will
with others, I decided to see if I could make SLIME protect me from
myself. As a quick proof of concept, I made this change to
swank-allegro.lisp:
Index: swank-allegro.lisp
===================================================================
RCS file: /project/slime/cvsroot/slime/swank-allegro.lisp,v
retrieving revision 1.82
diff -u -r1.82 swank-allegro.lisp
--- swank-allegro.lisp 10 Feb 2006 16:54:01 -0000 1.82
+++ swank-allegro.lisp 5 Mar 2006 18:09:36 -0000
@@ -85,6 +85,8 @@
"allegro")
(defimplementation set-default-directory (directory)
+ (unless (excl:probe-directory directory)
+ (break "~a not a directory." directory))
(let ((dir (namestring (setf *default-pathname-defaults*
(truename (merge-pathnames directory))))))
(excl:chdir dir)
@@ -500,7 +502,7 @@
(defmethod inspect-for-emacs ((o standard-object) (inspector acl-inspector))
inspector
- (values (format "~A is a standard-object." o) (allegro-inspect o)))
+ (values (format nil "~A is a standard-object." o) (allegro-inspect o)))
(defun allegro-inspect (o)
(loop for (d dd) on (inspect::inspect-ctl o)
(Hmmm, the last chunk of that patch looks like some minor bug fix that
I've had lying around that could usefully be applied to the mainline.)
But that raises two questions:
1) Is there a standard protocol for signalling errors from functions
that are invoked via comma shortcuts? At the moment simply
BREAKing does the trick in the sense that I can then abort out of
the debugger with no harm done but it seems a bit gross.
2) Is there some clever way to provide a *partial* default
implementation. That is, I'd like in swank-backend.lisp to do the
error checking (using a suitably portable replacement for
EXCL:PROBE-DIRECTORY) before doing the moral equivalent of a
CALL-NEXT-METHOD to get to the implementation-specific version. A
literal CALL-NEXT-METHOD won't work, it seems, since although
DEFIMPLEMENTATION expands to a method, it always expands to a
method with default (i.e. T) specializations on all its
parameters.
-Peter
--
Peter Seibel * peter at gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
More information about the slime-devel
mailing list