UNSUPPORTED-FUNCTIONALITY Error [was Re: Version 3.1.7.7 has been pushed]

[Robert Goldman]

While I don't agree with you about how debuggable ASDF is, nor the how
understandable are its failures, I DO agree with your feelings about
keeping the error simple.

Most of the error components I was suggesting do not provide useful
information to the user.

For the user, the important information is "why is this not supported?"
and that has to do with static information the programmer should supply,
rather than with information about what the current information is.

E.g., if an operation isn't supported on LispWorks 6.1, it doesn't help
to tell the user that they have LW 6.1: it helps to tell them why it's
not supported.

So what if I back off on making this more complicated, and we put in
just a capability name (which may be helpful to match both for testing
and for programming)?

That said, I would like feedback on how best to give feedback that's
helpful to the user.  E.g., if a features is not supported on LW 6.1
(but is supported on 7.0) or ABCL, then it's probably best for the ABCL
user to get an error message that the feature is not supported on ABCL,
but the LW user should get a message saying it's not supported on 6.1...
if this is possible without too much effort.

What about the following candidate?

(with-upgradability ()
  (define-condition unsupported-functionality (error)
    ((functionality
      :type string                      ;short name of functionality
      :initarg :functionality
      :reader functionality)
     (reason
      :initarg :reason
      :type (or string nil)                      ;format string
      :reader reason
      )
     (reason-args
      :initarg :reason-args
      :type list
      :reader reason-args
      ))
    (:report (lambda (c s)
               (with-slots (functionality reason reason-args) c
                 (if reason
                     (format s "~a is not supported in this environment
because ~?"
                             functionality reason reason-args)
                     (format s "~a is not supported in this environment."
                             functionality)))))))

If this seems reasonable, I will start testing it by trying to put it in
place of less specific calls to error.

One question I had was whether this should be a sub-class of
SIMPLE-ERROR, and instead of REASON and REASON-ARGS, I should have used
the standard FORMAT-CONTROL and FORMAT-ARGS.  Those names are more
informative about what the argument should be, but less informative
about how the arguments will be used (since in this case they will be
combined with the FUNCTIONALITY).

Thanks,
r