libasync icon indicating copy to clipboard operation
libasync copied to clipboard

Need a way to check the last socket error.

Open dazoe opened this issue 8 years ago • 2 comments

I'm working on writing a UDP based application, if my application receives certain ICMP packets it will trigger a READ event then when trying to read from the socket it will return 0 indicating an error. and setting the status to ABORT. I need a way to distinguish these error from other errors so I know it's safe to ignore them. I know there is error() but that returns a string. It'd be nice if there was access to the errorcode it's self.

BTW: phobos suffers from this issue as well. in phobos there is no way to get the last socket error code but they do have a public function for turning a socket error code into a string.

dazoe avatar Jan 27 '16 04:01 dazoe

These error codes are very specific to which OS you're using though. I think the you'd be better off checking the error code in libasync and tweaking the status directly from there

etcimon avatar Jan 27 '16 04:01 etcimon

I think that should be left up to the developer of the application that uses the library. For example my application is sending udp packets to many different other endpoints so receiving a "Connection reset by peer." error is safely ignored because I'll only send one packet and a timeout happens so I know when an endpoint doesn't want to talk to me. How ever someone else writing a different application that is attempting to send packets to a specific endpoint would be interested in receiving that error so they know when the packets are not wanted. I know this isn't a great example but I hope it gets my point across. The fact that the error codes will be different based on platform should be handled by the developer of the application, not the library. Unless you intend to create an error code map that combines all error codes into a common set of error codes. In which case you'll still have some error codes that are only used by one platform or the other, as well as error codes that don't match up well. I'm guessing on these last few statements because I don't know all of the error codes someone might encounter in socket programming and have little experience with programming socket based application for linux. Another reason to expose the actual error code is for researching what exactly failed. Just getting the description of the error may make it more difficult to figure out what happened.

dazoe avatar Jan 27 '16 04:01 dazoe

I'm not sure at this point if this was needed but with an example it definitely deserves a review if you had a fork.

etcimon avatar Feb 24 '23 22:02 etcimon