[m-rev.] IO error type

Volker Wysk post at volker-wysk.de
Thu Aug 18 00:54:43 AEST 2022


Am Mittwoch, dem 17.08.2022 um 17:59 +1000 schrieb Peter Wang:
> On Sun, 14 Aug 2022 10:38:00 +0200 Volker Wysk <post at volker-wysk.de>
> wrote:
> > The easier (and better?) way would be to make use of the errno
> > value
> > only. The table maps an errno value (an integer) to the name of the
> > error (a string, for instance "ENOENT"). It would also be possible
> > to
> > define a big enumeration type, which enumerates all the known errno
> > values. 
> > 
> > For instance, a function like this could be added to the io module,
> > which maps an IO error to the name of the errno:
> > 
> > :- func errno(io.error) = string.
> > 
> > This way, it would be possible to do something depending on *which*
> > IO
> > error occured, other than generating an error message.
> 
> Hi,
> 
> My proposal from Feb 2022 was this:
> 
>     :- type system_error.
> 
>     :- func make_io_error(system_error, string) = io.error.
> 
>     :- pred get_system_error(io.error::in, system_error::out)
>         is semidet.

This looks reasonable to me.

> That is, to introduce a backend/platform specific system_error type,
> and add a field for system_errors in the io.error type.
> (It would still be possible to construct an io.error without a
> system_error value.)

This way, the user could handle many errors either with the the non-
system_error part of io.error, or as a system_error. If desired, there
could be introduced new error handling information in the non-
system_error part... Such as (if desired) some standard errors with
standard error information. This would allow for a lot of flexibility.

Another consideration: We also have the POSIX standard, which is 
supported by all (?) platforms which the MMC runs on. When the errno
name would be used, code which is POSIX compliant could work accross
platforms. It would be up to the user to ensure that only portable
POSIX calls (and not Linux extensions) are used.

I don't know much (or nothing) about C# and Java, and the corresponding
grades, though.

> If we add your suggestion to allow converting an io.error to a name,
> we might have:
> 
> 	% Returns a standard error name if the given error corresponds
> 	% to a system error known to the Mercury system, e.g. "ENOENT"
> 	% (or possibly the name of a Java or C# exception?).
> 	% Fails if the error is not a system error, or if the error is
> 	% not one recognised by the Mercury system.
> 	%
>     :- pred get_error_name(io.error::in, string::out)
> 	is semidet.
> 
> 	% As above, but takes a system_error instead.
> 	%
>     :- pred get_system_error_name(system_error::in, string::out)
> 	is semidet.

I like this. Anyways, it will be necessary to translate errno values to
something which is the same accross platforms. Such as (preferably) the
errno name, or some big enumeration. The integer value of the errnos
won't do, since they can be different accross platforms.

> 
> Peter
> 
> PS. Other sources of errno names to scrape:
> 
>   - 
> https://github.com/jart/cosmopolitan/blob/master/libc/sysv/consts.sh
>   - https://docs.python.org/3/library/errno.html



More information about the reviews mailing list