This makes sense, since you can't call
WSAGetLastError() to retrieve the error value until
WSAStartup() succeeds since it will fail with
WSANOTINITIALISED
www.sockets.com/err_lst1.htm#SANOTINITIALISED
Windows Sockets does not support the Berkeley Sockets error variables
errno or h_errno because these per-process global variables don't allow for per-thread error information.
The WINSOCK.H header file provides a macro for
h_errno for Berkeley source code compatibility--simply calls
WSAGetLastError() The equivalent macro for
errno wasn't included since some applications use errno for non-socket (e.g. file handle) errors.
Most of the error values and their manifest constants (macros)
are derived from Berkeley Sockets.
The WinSock error values are the BSD
error values with a "WinSock API base" error WSABASEERR
www.sockets.com/err_lst1.htm#WSABASEERR
value added to each of them.
The macro for each WinSock API error is
the equivalent BSD error's macro, with the three letters WSA prepended to it.
So, for instance, the BSD manifest constant for the "would block" error was defined in the Berkeley Sockets
ERRNO.H header file as:
and WINSOCK.H redefines it as: #define WSAEWOULDBLOCK (WSABASEERR+35)
www.sockets.com/err_lst1.htm#WAEWOULDBLOCK
A few (lower value) WinSock error macro definitions refer to Microsoft C constants. In some cases, these redefine file access errors since Windows NT can treat a socket like a file handle.
A few other (higher value) macros are
entirely new to Windows Sockets.
They refer to error conditions unique to
Windows Sockets, such as invalid WinSock version requests, uninitialized
WinSock DLL access, or failed hostname resolution attempts.
All of the Windows Sockets error values have macros defined for
them in the WINSOCK.H header file.
They all have a "WSA" prefix and
their values are all biased by the WinSock API base error WSABASEERR
(10000) value.
See
list of user-fixable errors
The value for WSABASEERR
is fairly
arbitrary. It's high simply because error values in the Windows API are
high values by convention. There is a benefit, though: the unique bias
creates identifiable WinSock error values.
What Errors to Expect?
Don't assume the only errors you'll encounter are the ones listed with each function in the WinSock specification. Section 3.3.4 "Error Handling" in the v1.1 Windows Sockets specification warns against this:
Note that this specification defines a recommended set of error codes, and lists the possible errors which may be returned as a result of each function.
It may be the case in some implementations that other Windows Sockets error codes will be returned in addition to those listed, and applications should be prepared to handle errors other than those enumerated under each API description.
The specification is a common denominator among WinSock implementations. The errors it lists don't provide "fine resolution" in all cases, which means it doesn't account for some conditions that some network systems can detect.
Finer resolution in error reporting is a double edged sword: with more accurate error values it's easier to diagnose problems when they occur, but it's also more difficult to write an application that can handle all contingencies.
The better prepared your application is for any error, the more gracefully you'll handle it, and the easier you'll make your job and the job of your support staff.
Page 2/3 -
User Fixable Errors
|
Page 1/3
(This page) - Winsock Error Codes
Page 2/3 -
User Fixable Errors
-
There are two basic types
of errors: those an application user can remedy, and those he cannot.
A
user should never see an error that is not user-fixable.
Page 3/3 -
List of user-fixable
errors
|
|
