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

[Faré]

I'd rather keep it simple.

End-users don't care WHY something is failing, just THAT it is failing
gracefully and that the reason for failure is known. Users
(programmers) can use M-. from the error to find the source and
comments. A short link to a suitable cliki.net page might help explain
the proper investigation procedure.

I see no reason for some programmer-intensive protocol that leads to
large image size increase for no clear benefit that M-. won't bring.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Those "organizers" who confuse coordination and cooperation will have 100%
coordination for 0% cooperation. All costs, no benefits.


On Thu, Aug 25, 2016 at 10:37 PM, Robert Goldman <rpgoldman at sift.net> wrote:
> On 8/23/16 Aug 23 -9:55 AM, Elias Pipping wrote:
>>
>>> On 23 Aug 2016, at 15:50, Robert Goldman <rpgoldman at sift.net> wrote:
>>>
>>> On 8/23/16 Aug 23 -6:42 AM, Elias Pipping wrote:
>>>> If we can agree on Robert’s unsupported-functionality error class, I’ll work that into the merge request, too.
>>>
>>> I have a busy day today, but I will try to get it done.
>>>
>>> I was thinking of having slots for:
>>>
>>> - implementation
>>> - capability name
>>> - optional format control and format args that the programmer can use to
>>> provide additional information.  E.g., for LW, say that it's for
>>> licensing reasons that the DELIVER capability is not available.
>>>
>>> If this sounds reasonable, I'll put it in, and try to find places it
>>> should be used.
>>>
>>> In an earlier email, Elias points out that there are related reasons why
>>> a function might have failed.  I haven't had time to figure out whether
>>> these would call for additional condition classes.
>>
>> I was thinking: We’re trying to tell the user that what they’re doing does not
>> work. Yes, the function does exist, you’re passing the right number of
>> arguments and the right keywords but there’s a problem. The problem could be:
>>
>>  - Your lisp is very old or very new or nobody’s gotten around to looking into
>> it, so even though your lisp might provide the necessary functionality, the
>> wrapper hasn’t been made to cover it yet (that’s what the master branch
>> currently uses (error “not implemented: ~S” #’function-name) for)
>>  - You’re passing a combination of parameters that is not supported on this
>> lisp (that’s what the master branch currently uses (assert) for)
>>  - The function or combination of parameters you’re calling it with is
>> affected by a known bug on your lisp that we cannot work around.
>>
>> I was thinking that to the user, it does not make a difference which one of
>> those three reasons a function call fails for, so we could use one condition
>> for all three, and unsupported-functionality captures the concept pretty well.
>>
>> The capability name would often have to be a rather long description than just
>> a name this way, though, I’m afraid. I’m not sure if I understand the purpose
>> behind the ‘implementation' key of the condition. If a feature is e.g. missing
>> on lisp A and B, and you’re on lisp A, if would simply contain “A”? Or would
>> it contain something like “A personal edition prior to version 2.5?”
>
> I was focusing on the implementation, and perhaps a version number,
> because I have mostly been thinking about how I would use this new error
> class in the tests. In particular, I was thinking of running the tests
> on all lisp implementations, and catching expected failures, rather than
> doing what we do now, which is disable the tests on platforms where we
> believe a function is not available.
>
> If we were to run tests on all implementations/platforms, and catch
> expected errors, that would help us detect unexpected successes, when
> functionality that used to be broken starts to work.
>
> Well, I have also been thinking about how nice it would be to have an
> understandable, standard error message for users who use an unsupported
> function by accident.
>
> What about:
>
> 1. Capability -- what we were trying to do.
> 2. Implementation name -- string, or could be a keyword, if we were to
> add a list of keywords.
> 3. Optional version number
> 4. Optional platform (for, e.g., "this works on SBCL > 1.2, but not on
> Windows.")
> 5. Additional information (e.g., LW personal edition)
>
> We could have a signal-unsupported-capability function that would
> auto-collect some of these slot values, to make this easier to use.
>
> There's no tearing hurry for this, so I'm happy to have some more email
> cycles so that we can get it right.
>
> Best,
> r