Re: Generic C API error SRFI Lassi Kortela 27 Jun 2020 20:45 UTC
> Hence the generic Scheme framework could be like: > > Okay, this makes a lot of sense to me. So this has nothing to do with > Scheme errors: it's a way of reflecting errors from arbitrary C APIs > into the Scheme condition system. Exactly. Well, the SRFI's API should be able to create Scheme exception objects that are easy to raise. But the API should probably not raise them itself; that should be deferred to the user. > That being so, I think c-error or external-error is the best name for it. I like those names. `external-error` is probably better since the same framework could probably be used as-is for errors coming from Java or other FFI languages. `environment-error` is another possible name (by analogy with environment variables, etc.) But it's getting quite verbose. `foreign-error` is another possibility, though perhaps a bit confusing. The errors do not need to come from the FFI even though that will probably be the most common source. > - Name of C API that caused the error (as a symbol or string) > - Name of C constant for the error code (as a symbol or string) > > Both of these should be symbols. LGTM > - Error message (in English, or a localized one if English not > available) > - Localized error message (where available) > > Since strerror()'s return is already localized, I think there should be > just one string slot. Nobody except a human being should be looking at > it anyway: the other arguments are meant for computers to dispatch on. IIRC, WinAPI can handle a situation where multiple localizations of the same set of error messages are installed. By default, Windows (at least old versions) installed only one set of messages and they were localized, which meant that the English messages were not available on non-English editions of Windows. This was a culture shock to a programmer expecting (US) English to be the lingua franca of computing. Not sure what the situation is nowadays. I suspect GNOME and perhaps KDE will also offer localized errors. Probably other big software packages as well. It might be best for each "error message" to actually be an association list of (language . "message") pairs. Users who don't care about which locale they get can simply retrieve the first one. > In addition to these accessors, the API would expose a constructor, a > constructor-raiser convenience procedure, and a predicate, and would > become what SRFI 198 is all about. LGTM > Do we have consensus now? I'm happy with what's proposed so far.