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

[Faré]

On Fri, Aug 26, 2016 at 9:24 AM, Robert Goldman <rpgoldman at sift.net> wrote:
> 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.
>
My contention is that the programmer cannot supply this information.
Certainly not in a maintainable way.

Any accurate compatibility grid must be outside the source code.

As a programmer:
You can't predict the bug in your code.
You can't predict the bug in the implementation.
You can't predict when the implementation will be fixed.
You can't predict when ASDF will be fixed to support the implementation.
>From the ASDF 2 principle "None shall have to input (and make up)
information he doesn't have",
it is therefore NOT the responsibility of the programmer to tell the
user which versions will or won't work.

And that goes not just for ASDF. Any user who expects to get this
information from the program is a fool.
If you believe there are too many such fools, include a URL to explain
that to them
-- and you'll be left with the bigger fools who still don't get it.
If you're using a many-years-old version of LispWorks, something fails in ASDF,
and you don't think of upgrading either LispWorks and/or ASDF, you're
such a bigger fool.

> 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)?
>
Yes, that's the one (and only) piece of information that needs to be included
in the error message.

> 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.
>
I would remove reason and reason-args. There's nothing useful the
programmer can tell.

On the other hand, I would define a function that throws the error,
because that's worth it:

(defun unsupported-functionality (functionality)
   (error 'unsupported-functionality :functionality functionality))

And yes, FORMAT-CONTROL and FORMAT-ARGUMENTS would be better names than REASON.

-#f