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