We salvage [a malformed plist handed to make-foreign-status or raise-foreign-error] it by packaging up everything starting with where the plist is broken, 'oops in this case, and putting it under a 'malformed-arguments key. Most certainly do no throw it away [ ADDED NOW: or just use the 'args key, it's accurate for this purpose. ]
I think we do. This is not an external contingency we need to be prepared for; it's a programming error. It is Scheme code that constructs a foreign-status object from the external API, its own tables, files, etc. If that code is wrong, the program is wrong.
Problem is, make-foreign-error only gets called when the error is signaled, not at load/compile time, unless we want to turn it into a fancy macro. Which might be OK, but barring that, I maintain a strong position to throw no information away from malformed calls to make-error-object. Even if the argument handed to it is a number
instead of a list.
Whereas I take the position that if the arguments to the constructors are malformed, you can't trust *any* of the data. When a clock strikes thirteen, you shouldn't just decide to keep the first twelve strokes and stash the thirteenth one somewhere. The clock is broken and you have no idea what time it is, and that's what you need to report.