This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

how can I reliably learn why a system call failed?



I'd like to write some code that gracefully handles failed system
calls.  For example, I'd like to call (mkdir "foo") and return an
error if the call fails for most reasons, but return success if the
call fails with "File exists".  Thus, I want to know why mkdir
failed.

When I do make such a failing call, I see that the exception that gets
thrown looks like this:

        (system-error "mkdir" "%s" ("File exists") (17))

Apparently, this list is in the format described by the argument list
of the function `scm-error'.  But that's just a guess; I couldn't find
any documentation that says "when a system call fails, it will throw
an exception, and the information in the exception comes from the
arguments to scm-error".

I suppose I could simply examine the fourth element, and if it is a
list that contains the string "File exists", I can assume that the
call failed because the file existed :).  But this feels strange.  I
wonder if that message might sometimes be different -- for example, if
my code runs on a system in Barcelona, perhaps the message would be in
Spanish -- in which case it would be a mistake for me to make
decisions based on the text.

And I suppose I could test against the numeric data -- but unless I
parse errno.h myself, I don't see how my program is supposed to know
that the number 17 means EEXIST.

So ... what's the reliable, portable way to do this?

Thanks

-- 
PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5  C8BD 6337 0041 C01C 5276

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]