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

[Elias Pipping]

> On 26 Aug 2016, at 04:37, Robert Goldman <rpgoldman at sift.net> wrote:

Dear Robert,

> 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.

yes, I was hoping for that, too. It's what prompted me to suggest extending unsupported-functionality to cover the three types of expected errors I was seeing.

> 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.

I agree. I think the transition from user to developer is smooth. With a descriptive error message, a person might be able to understand what the problem is right away (oftentimes, the solution will be that they’ll just have to a use a newer version of the lisp they’re on), he or she might be able to find somebody with the very same problem (and an explanation or solution) on his or her favourite search engine, etc.

> 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.

Like *implementation* from test/script-support.lisp?

> 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)

Indeed it seems like 'personal edition' doesn’t fit into (2) or (3) this way. (It would fit better into (2) than (3) if the keywords allowed for that, I think). Those five fields should suffice, though.

We could also just use (lisp-implementation-type) and (lisp-implementation-version) for (2) and (3) instead of coming up with a custom solution.

> We could have a signal-unsupported-capability function that would
> auto-collect some of these slot values, to make this easier to use.

I’d like to avoid misleadingly precise error messages though (think "this feature is not implemented on some-lisp 19.3.2 running inside cygwin on 32-bit windows” which could be generated from automatically retrievable information) when we’ve simply not gotten around to implementing the function on some-lisp or windows at all. (the message would suggest that upgrading to version 20 might help which it would not).

> There's no tearing hurry for this, so I'm happy to have some more email
> cycles so that we can get it right.

Actually, it’s now been the one thing that’s been keeping me from working on my run-program changes because a considerable part of the changes I already have adds or cleans up handling of errors. But it probably shouldn’t be. I’ll try to isolate the bug fixes better from the invasive changes and have the latter queue up after the unsupported-functionality proposal. Because you’re right, this shouldn’t be rushed, and at the same time, bug fixes shouldn’t have to wait.


Elias

PS: Obtaining printable version information for (2) is not difficult. Checking if the current version is more recent than another version will generally be hard to impossible, in contrast. We desperately need such checks, though, if we want to generate errors in a reliable fashion.