A #commonLisp #conditionSystem #gopher take 2.
Previously I signalled a gopher-request: The server matched the item specifier in an alist, and chose an itemtype restart.

As you know, this is wrong: rfc1436's *client* chooses how to interpret the response.

Instead I guess these are the layers of restarts:

Server has all its item specifiers as restarts.

All of these restart to copying the "byte" stream to the client.

The client restarts the response stream to their chosen itemtype restart.

@screwtape

Well, the totality can be a function of other than args, so something that takes any kind of args can still err for other reasons. I don't know if that helps.

I don't know if you've read these papers but you might find them a bit more abstract:

http://www.nhplace.com/kent/Papers/Exceptional-Situations-1990.html

http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html

The second of those is mostly more advanced topics, as I recall. But the first is a discussion of the same issues as you find in Revision-18.txt, but in a way that is hopefully more abstract. That 1990 paper won a Best Paper award at the First European Conference on the Practical Application of Lisp, so I assume it was decently readable. It was just a dusting off of the paper I'd written in 1985 that no one had really cared about for 5 years. Since the paper was already written, I used the prep time for the conference to polish, and to whittle away anything about the paper that might not look like a "best paper", which apparently worked. :)

The 1985 paper is here, though I recommend just reading the 1990 version. I just often speak in hypertext and feel compelled to link things I talk about:

https://dspace.mit.edu/bitstream/handle/1721.1/41474/AI_WP_268.pdf

#lisp #CommonLisp #exceptions #errors #ErrorSystem #ConditionSystem

cc @masso

@lanodan @cwebber The #CommonLisp #ConditionSystem is more than powerful enough to handle the task just fine.

I do not consider the unstructured text/binary stream approach of Plan9's "everything is a file even more" desirable.

It makes #interoperability a nightmare and any reliable structured use then requires ad-hoc structuring through additional serialization.

@h @Seirdy That's mostly because try/catch is a very weak paradigm for error handling and profoundly limiting.

The #CommonLisp #ConditionSystem is rather the way to look.

@speskk @katco

I think this can work well when coders take the effort to use the #CommonLisp #ConditionSystem.

Using it well usually leads to writing less tests & investing the time freed into providing structured hooks to users by which they can do reasonable analysis of error situations & responsibly restart from errors.

It's also closely related to #CAP, because the better Conditions & Restarts are designed,the better the experience in the debugger.

🌺

🔗 https://t.me/FamilyOfLisp

🏷️ #Lisp