[m-users.] io.error type
Julien Fischer
jfischer at opturion.com
Sat Feb 5 13:51:58 AEDT 2022
Hi Peter,
On Sat, 5 Feb 2022, Peter Wang wrote:
> On Fri, 04 Feb 2022 15:52:38 +0100 Volker Wysk <post at volker-wysk.de> wrote:
>> Am Freitag, dem 04.02.2022 um 12:54 +0100 schrieb Fabrice Nicol:
>> > So yes, errno codes could have been returned, if is_error had been
>> > publicly visible, but design decisions went against this.
>>
>> How are the chances that this will be changed? Not being able to determine
>> which error occured, is kind of grave.
>
> I agree it would sometimes be useful to get a machine-usable reason for
> an error. I think we should add something like:
>
> % Get a system-specific error code associated with an error,
> % if any. On C backends, the error code should be an errno
> % value.
> %
> :- pred system_error_code(io.error::in, int::out) is semidet.
My inclination would be to just to store the system_error value in the
io.error type, rather than turning into an int. If we document
what the target language representation of a system_error value is,
then it will be "helpful" for the C# and Java backends as well.
(The io.error type would continue to contain its current string field,
since removing it would break code that calls io.error_message.)
Julien.
More information about the users
mailing list