Re: Clearing up confusion, and Windows errors as POSIX errno's
hga@xxxxxx 15 Aug 2020 16:50 UTC
> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Friday, August 14, 2020 10:27 AM
>
> Hmm, how about this:
>
> (make-foreign-error
> 'set 'windows
> 'number 2
> 'name 'ERROR_FILE_NOT_FOUND
> 'message "File not found"
> 'errno-name 'ENOENT) ; <---------
Errr, are you here implying plists without the list as the argument to
make-foreign-status and raise-foreign-error? That's more than OK, at
first thought.
I would do it as something like:
(raise-foreign-error
'set 'posix
'subset 'windows
'errno 2 ; I'm lying, but eh.
'name 'ERROR_FILE_NOT_FOUND
'message "File not found"
'errno-name 'ENOENT) ; I'm lying, but eh.
In the above, we'd use 'errno-name in the 'posix 'set to not reserve
the very common and generic 'name for other uses. From that
viewpoint, 'errno-number would also be very good, it's certainly all
but totally unambiguous, whereas our discussions have show 'errno can
be interpreted in a zillion ways. So:
(raise-foreign-error
'set 'posix
'subset 'windows
'errno-number 2 ; I'm lying, but eh.
'name 'ERROR_FILE_NOT_FOUND
'message "File not found"
'errno-name 'ENOENT) ; I'm lying, but eh.
> The 'errno-name property could be a generic one for mapping the native
> errors from various systems into equivalent errnos, on a close-enough
> basis. For example, any kind of "file not found" error could be mapped
> to 'ENOENT.
Or just use it in all cases. We want all 'posix 'sets to be regular,
and the 'subset 'windows key/value pair whispers "We're lying to you
for your own good."
> Using ('set 'errno 'name ENOENT 'number 2) is a bit deceptive when we
> know the error is from the Windows API and know the GetLastError() code.
> We should return the native Windows code instead. But if we add an extra
> 'errno-name that should give the best of both worlds.
Agreed to all points.
> Perhaps 'errno-equivalent, 'errno-equiv or a simple 'errno as Harold
> suggested would be a better name for the property. Users who care about
> portable code would be writing code like this:
To keep it portable and more clear, 'errno-name, so I modify what you did
below to:
> (define (read-symlink-if-exists path)
> (guard (err ((and (foreign-status? err)
> (eq? 'ENOENT (foreign-status-ref err 'errno-name)))
> #f))
> (read-symlink path)))
Back to the real you:
> That doesn't look bad to me, especially given that Windows could be
> supported with the same code while preserving native WinAPI error
> information.
- Harold