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 <rpgold...@sift.net> wrote: > On 8/23/16 Aug 23 -9:55 AM, Elias Pipping wrote: >> >>> On 23 Aug 2016, at 15:50, Robert Goldman <rpgold...@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
