[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.)


More information about the users mailing list