> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Sunday, June 28, 2020 10:10 AM
>
> [...]
>
>> Foreign "procedure" might be too specific, e.g. the PostgreSQL wire
>> protocol has "messages" rather than "procedures."  Maybe something
>> like "action"??
>
> Also a good point. I can't think of a good term. Maybe we should
> collect many error sets and then revisit the question.

Consulted thesaurus.com, and perhaps interface, as in "Foreign
Interface Error [we need another instead of exception]".  By
definition, if it's "foreign", we're making an interface to it.  Two
other good ones:

"Routine", "Foreign Routine Error [whatever]"
"Operation", Foreign Operation Error [whatever]"

Some not so good possibilities:

mechanism
task
use
work

Words that I generally like that don't fit but might provide
inspiration:

instrumentality
manipulation
red tape (this *is* stuff that's not getting the job done per se)
reply
return
transaction (too overloaded, especially to use in a title without context, such as the SRFI page).

>> Do we want to expose make-foreign-error in the API?  The style John
>> has used so far hides that inside the function that raises an error.
>> But that's because he has these APIs raise errors, we shouldn't
>> preclude someone from creating a foreign API where errors are returned
>> instead of raised.
>
> Being able to create an error object without raising it will surely
> prove to be valuable.
>
> I'm neutral on whether or not the SRFI should provide its own `raise`
> procedure; I'll let you and John decide.

We might as well, it's system dependent, we don't need to force
everyone who wants to raise an exception to duplicate effort.
Similarly, output as a single string, as a string or to a port.

>> Here I'm going to ask if there's any good reason to not explicitly
>> break out "arguments" from data.  That information is so valuable we
>> should strongly encourage developers to include it, without making
>> it mandatory.
>>
>> Of course, this fits cleanly into turning data into an alist, but how
>> about adding a standard set of key symbols that might appear there,
>> like 'arguments, and:
>
> If by "arguments" you mean procedure call arguments, it's a very good
> idea to support carrying arglist information in the exception object.

Yes, although John believes this is highly optional.

> I don't have an opinion on whether to have a separate user-data alist,
> or a single alist of all properties where some keys simply have standard
> meanings specified by SRFI 198.

I'm inclined towards the latter, the top level surface should be as
small as practical.  Already there's a whole bunch of items in an error.

> Similar concerns apply to a generic logging framework with pluggable
> backends (file, pipe, syslog, json lines, etc.). We could perhaps design
> a logging framework in tandem with SRFI 198.

Hmmm.  At the very least, the string/port output ought to be able to
target logging.

>> At this point, populating each error constructor invocation is getting
>> onerous.  Conventions, or a mechanism to set defaults for the contents
>> of a file, library, or whatever would I think be welcome, albeit the
>> latter being somewhat dangerous.
>
> Good point. Agreed. I don't have any proposal for the details thought up.

Will put it on my TODO list.

- Harold