[m-rev.] IO error type

Volker Wysk post at volker-wysk.de
Sun Aug 14 18:38:00 AEST 2022


Hi!

The io.error type is abstract and all that can be done with it, is to
produce an error message. Lately I had the situation that I needed to
do something depending on which error it is. This isn't possible. I
think that's a rather grave limitation.

Some one and a half years ago, I was facing a similar situation with
SWI-Prolog. SWI-Prolog has some exceptions which are raised, depending
on which IO error occurs. But those exceptions weren't very suitable.
(I don't remember the details). 

In order to remedy, I've talked to Jan Wielemaker and I worked out a
simple scheme for the handling of POSIX errors. For some of them,
existing or new exceptions were to be defined. For others, die POSIX
errno value was to be thrown in a generic exception, which covers all
remaining errno values.

I've spent hours researching all possible errno values and determine
the SWI-Prolog excpetions which they should be mapped to. There are the
errno values which are standardised in the POSIX standard, a lot of
(badly documented) extra errno values in Linux and some in Windows.

The work wasn't completed, because Jan wasn't willing to fill out the
remaining parts and function definitions for the SWI-Prolog foreign
language interface. At that time I was switching completely to Mercury,
and was losing interest. 

I've attached the resulting C source file (errno_error.c), which was to
 be incorporated into SWI-Prolog.

Now I think, that this code could be used to improve the handling of IO
errors in Mercury. 

It could either be done with some predefined error values, which would
be returned in case of an error, or be thrown as an exception, similar
to SWI-Prolog. Or it could be done completely based on the POSIX errno
value. 

The errno values are defined as C macros and may be different on
different platforms. So a C file is needed, which maps those errno
values to something the Mercury side can understand. Most of the
errno_error.c file does just that, and provides comments describing the
error and when it occurs. I've collected those descriptions from
various sources (see the errno_error.c file). Those comments would be
relevant when specific values/exceptions for some of the errors should
be defined, like in SWI-Prolog.

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.

Cheers,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: errno_error.c
Type: text/x-csrc
Size: 36864 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20220814/1540e734/attachment-0001.c>


More information about the reviews mailing list