[m-users.] io.error type
novalazy at gmail.com
Sat Feb 5 17:19:15 AEDT 2022
On Sat, 05 Feb 2022 13:51:58 +1100 Julien Fischer <jfischer at opturion.com> wrote:
> 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.)
Yes, that seems better. So we have:
:- type io.error
---> io_error(system_error, string).
:- func make_io_error(system_error, string) = io.error.
:- pred get_system_error(io.error::in, system_error::out)
An io.error value constructed by make_io_error/1 will have a dummy
system_error in the first argument; it can be -1 or null.
More information about the users