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

[Robert Goldman]

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