Euphoria
Ticket #66:
Socket functions need better error handling
-
Reported by
mattlewis
Sep 14, 2009
Currently, the standard way that our socket functions handle errors is to return the error number returned by the underlying socket API. This can be ambiguous with success. For instance, send() returns a positive integer denoting the number of bytes sent.
Also, some demos and tests do not correctly check for error conditions. sock_server.ex, for instance, assumes that bind will return 0 or 1, when in fact it may return a positive integer upon error.
Details
1. Comment by jeremy
Sep 14, 2009
In the example of send... what would you rather it do?
2. Comment by mattlewis
Sep 14, 2009
I don't know about send, but I've just committed some fixes to t_socket.e and sock_server.ex so that they at least check for the return value to be 1 to consider success.
I suppose we have a couple of options with functions like send. We could simply return 0, and let the user make another call to check for the errno, or we could return a sequence with the errno as the only element. For stuff like connect, I suspect the idiom:
if connect(...) then
...will be nearly irresistible. I dislike the way that value() returns its status. Maybe we should convert everything to be a sequence upon success, integer representing failure upon failure. How will people be using the return value of, e.g., send()? (I have no idea if this is a major inconvenience or not, but I think we should try to be consistent with the API.)
3. Comment by jeremy
Sep 14, 2009
I guess I have used the C functions so much, I'm just use to it. Other API's use things such as 0 on success any other value is an error code.
What I had planned on doing is making constants, so you would say:
if connect() = socket:OK then hello. end if
on send, I thought:
if not send("HELLO") then
-- handle error
end if
Or, if you need to know how many bytes were sent:
integer sent = send("HELLO")
if sent = 0 then
-- handle error
end if
4. Comment by mattlewis
Sep 14, 2009
Yeah, those proposals would work. Technically, the existing situation would sort of work (until you happened to send the same number of bytes as an error message in sendI don't know if similar situations exist with other functions).
The con in using a constant like that is that many people will try to use the 'simple' way out. Of course, assuming it's documented properly, this would be their fault, but as we know, that doesn't make it the right/best way to do things. As long as our demos and tests check correctly, I'll probably be happy. 
5. Comment by jeremy
Sep 14, 2009
Error messages will be negative values.
6. Comment by jeremy
Sep 17, 2009
Harmonization of the error codes is completed. sock_server and sock_client have been updated. Other demos have not yet been fixed.
7. Comment by jeremy
Sep 17, 2009
New error code harmonization is complete. Internal code, Tests and Examples have all been updated.
8. Comment by mattlewis
Sep 17, 2009
Hooray!
GitHub