[slime-devel] giving reasons for RPC aborts

[Taylor R Campbell]

   Date: Fri, 29 Jun 2007 13:54:31 +0200
   From: Helmut Eller <heller at common-lisp.net>

   I dislike this idea.  Why can't the function just return an error
   indicator together with the error message if it can't complete
   normally?  I think we shouldn't add an exception system for RPCs.
   Tagged return values are easy to understand and good enough for the
   job.

Is it really better to extend N different callees of `slime-eval' and
friends to accept a tagged result to distinguish OK responses from
errors, when the RPC mechanism already has one?  All of the callers
where it is possible for a user error to arise would have to be
modified to expect a possible error response -- say, remote callers of
SWANK:SET-PACKAGE when the package doesn't exist,
SWANK:SWANK-TOGGLE-TRACE or a number of other similar operations when
the function in question is not defined, SWANK:GET-REPL-RESULT when
the result is unavailable, and so on.

   Also, dropping into the debugger seems to be the proper action to
   take.  If SLIME doesn't handle the returned value it's obviously a
   bug.  (And the bug will be fixed sooner if the debugger pops up.)

Sorry, I'm a little unclear:  Do you mean that it is the proper action
to take to drop into the debugger for the above examples, where there
is a single uniquely best course of action (namely, for the user to do
something else after being presented with an error message); or that
all of the RPC interfaces where user errors are possible should be
changed to support them, and that any callers that don't deal with the
errors gracefully should drop into the debugger?