Date: Fri, 29 Jun 2007 13:54:31 +0200 From: Helmut Eller heller@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?