How about design a subclass which extends from SocketException, looks like:
class SocketWithErrorCodeException extends SocketException { SocketWithErrorCodeException (String message, int errorCode) { super(message); this.errorCode = errorCode; } private int errorCode; public void get/setErrorCode() ; } Native code throws SocketWithErrorCodeException instead of SocketException so that java code could process different error by invoking e.getErrorCode (). Does that make sense? Thanks! On 7/13/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
I agree with the reason why (I think I understand it - you don't want to rely on the result of getMessage() to determine the problem...) Could you wrap the socket exception to carry a simple integer error code? geir Mikhail Loenko wrote: > -1 for applying the patch > > Applying this patch means creating a hidden problem > > Thanks, > Mikhail > > 2006/7/12, Jimmy, Jing Lv <[EMAIL PROTECTED]>: >> Andrew Zhang wrote: >> > Hello Mikhail, >> > >> > Please see my comments inline. >> > >> > Thanks! >> > >> > >> > On 7/12/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: >> >> >> >> 2006/7/12, Andrew Zhang <[EMAIL PROTECTED]>: >> >> > Hi Mikhail, >> >> > >> >> > It's a NON-NLS message. >> >> > >> >> > Native code is designed in this way. Currently, Harmony socket >> native >> >> code >> >> > uses messages in SocketException to identify error type. >> >> > >> >> > To avoid the confusion, two alternatives way I could image are: >> >> > >> >> > 1. Native code returns platform-independent error code. >> >> > >> >> > 2. Native code throws different exceptions, which are all >> extended from >> >> > SocketException. >> >> > >> >> > Anyway, as current Harmony native design, the message in >> >> SocketException >> >> > thrown by native code is a NON-NLS string, that is to say, like >> >> "GET","POST" >> >> > in http protocol. Unless we take a big change on native code >> design, I >> >> > don't think the code is dangerous. >> >> > >> >> > What's your opnion? >> >> >> >> I like option #2. >> > >> > >> > I also prefer option1 and 2 to current native solution. >> > >> > I don't think exception messages are the same as "GET" and "POST", we >> > agreed >> >> that the messages are to be internationalized. I see that currently >> not >> >> all >> >> the messages are internationalized but I think they will in the >> future. >> > >> > >> > NO. Currently, exception message thrown by native code are used as >> if error >> > code [1]. Please pay attention to netLookupErrorString function. >> > >> > Harmony-815 patch is based on current Harmony native implemenation, >> > therefore, it should work well if design is not changed. >> > >> > If we decide to adopt option 1, or 2, we have to re-design native >> and java >> > interface, >> > >> > and there are lots of native and java code to be changed. >> > >> > How to design native interface is out of scope to this patch, >> therefore, I >> > think a seperate JIRA or thread for socket native interface design >> is more >> > suitable. >> > >> > Of course, once decision is made, I'll volunteer to revise native >> and java >> > code. >> > >> >> Yep, I also find this strange style of return value, I doubt if the >> exception thrown in native may be an enhancement to code efficiency? >> However to refactor this may be a heavy work, as much code follows this >> style, affects both luni and nio. I suggest apply this patch, and leave >> this work until Harmony begins i18n. >> >> > Does it make sense? >> > >> > Thanks! >> > >> > [1] native-src (nethelp.c) >> > >> > >> > void >> > throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber) >> > { >> > jclass aClass; >> > /* the error message lookup should be done before the FindClass call, >> > because the FindClass call >> > * may reset the error number that is used in hysock_error_message */ >> > >> > // !!! Here, error code is mapped to NON-NLS mesage. >> > char *errorMessage = netLookupErrorString (env, errorNumber); >> > aClass = (*env)->FindClass (env, "java/net/SocketException"); >> > if (0 == aClass) >> > { >> > return; >> > } >> > (*env)->ThrowNew (env, aClass, errorMessage); >> > >> > } >> > >> > char * >> > netLookupErrorString (JNIEnv * env, I_32 anErrorNum) >> > { >> > PORT_ACCESS_FROM_ENV (env); >> > switch (anErrorNum) >> > { >> > case HYPORT_ERROR_SOCKET_BADSOCKET: >> > return "Bad socket"; >> > case HYPORT_ERROR_SOCKET_NOTINITIALIZED: >> > return "Socket library uninitialized"; >> > case HYPORT_ERROR_SOCKET_BADAF: >> > return "Bad address family"; >> > case HYPORT_ERROR_SOCKET_BADPROTO: >> > return "Bad protocol"; >> > case HYPORT_ERROR_SOCKET_BADTYPE: >> > return "Bad type"; >> > case HYPORT_ERROR_SOCKET_SYSTEMBUSY: >> > return "System busy handling requests"; >> > case HYPORT_ERROR_SOCKET_SYSTEMFULL: >> > return "Too many sockets allocated"; >> > case HYPORT_ERROR_SOCKET_NOTCONNECTED: >> > return "Socket is not connected"; >> > case HYPORT_ERROR_SOCKET_INTERRUPTED: >> > return "The call was cancelled"; >> > case HYPORT_ERROR_SOCKET_TIMEOUT: >> > return "The operation timed out"; >> > case HYPORT_ERROR_SOCKET_CONNRESET: >> > return "The connection was reset"; >> > case HYPORT_ERROR_SOCKET_WOULDBLOCK: >> > return "The socket is marked as nonblocking operation would >> block"; >> > case HYPORT_ERROR_SOCKET_ADDRNOTAVAIL: >> > return "The address is not available"; >> > case HYPORT_ERROR_SOCKET_ADDRINUSE: >> > return "The address is already in use"; >> > case HYPORT_ERROR_SOCKET_NOTBOUND: >> > return "The socket is not bound"; >> > case HYPORT_ERROR_SOCKET_UNKNOWNSOCKET: >> > return "Resolution of the FileDescriptor to socket failed"; >> > case HYPORT_ERROR_SOCKET_INVALIDTIMEOUT: >> > return "The specified timeout is invalid"; >> > case HYPORT_ERROR_SOCKET_FDSETFULL: >> > return "Unable to create an FDSET"; >> > case HYPORT_ERROR_SOCKET_TIMEVALFULL: >> > return "Unable to create a TIMEVAL"; >> > case HYPORT_ERROR_SOCKET_REMSOCKSHUTDOWN: >> > return "The remote socket has shutdown gracefully"; >> > case HYPORT_ERROR_SOCKET_NOTLISTENING: >> > return "Listen() was not invoked prior to accept()"; >> > case HYPORT_ERROR_SOCKET_NOTSTREAMSOCK: >> > return "The socket does not support connection-oriented service"; >> > case HYPORT_ERROR_SOCKET_ALREADYBOUND: >> > return "The socket is already bound to an address"; >> > case HYPORT_ERROR_SOCKET_NBWITHLINGER: >> > return "The socket is marked non-blocking & SO_LINGER is >> non-zero"; >> > case HYPORT_ERROR_SOCKET_ISCONNECTED: >> > return "The socket is already connected"; >> > case HYPORT_ERROR_SOCKET_NOBUFFERS: >> > return "No buffer space is available"; >> > case HYPORT_ERROR_SOCKET_HOSTNOTFOUND: >> > return "Authoritative Answer Host not found"; >> > case HYPORT_ERROR_SOCKET_NODATA: >> > return "Valid name, no data record of requested type"; >> > case HYPORT_ERROR_SOCKET_BOUNDORCONN: >> > return "The socket has not been bound or is already connected"; >> > case HYPORT_ERROR_SOCKET_OPNOTSUPP: >> > return "The socket does not support the operation"; >> > case HYPORT_ERROR_SOCKET_OPTUNSUPP: >> > return "The socket option is not supported"; >> > case HYPORT_ERROR_SOCKET_OPTARGSINVALID: >> > return "The socket option arguments are invalid"; >> > case HYPORT_ERROR_SOCKET_SOCKLEVELINVALID: >> > return "The socket level is invalid"; >> > case HYPORT_ERROR_SOCKET_TIMEOUTFAILURE: >> > return "The timeout operation failed"; >> > case HYPORT_ERROR_SOCKET_SOCKADDRALLOCFAIL: >> > return "Failed to allocate address structure"; >> > case HYPORT_ERROR_SOCKET_FDSET_SIZEBAD: >> > return "The calculated maximum size of the file descriptor set is >> > bad"; >> > case HYPORT_ERROR_SOCKET_UNKNOWNFLAG: >> > return "The flag is unknown"; >> > case HYPORT_ERROR_SOCKET_MSGSIZE: >> > return >> > "The datagram was too big to fit the specified buffer, so truncated"; >> > case HYPORT_ERROR_SOCKET_NORECOVERY: >> > return "The operation failed with no recovery possible"; >> > case HYPORT_ERROR_SOCKET_ARGSINVALID: >> > return "The arguments are invalid"; >> > case HYPORT_ERROR_SOCKET_BADDESC: >> > return "The socket argument is not a valid file descriptor"; >> > case HYPORT_ERROR_SOCKET_NOTSOCK: >> > return "The socket argument is not a socket"; >> > case HYPORT_ERROR_SOCKET_HOSTENTALLOCFAIL: >> > return "Unable to allocate the hostent structure"; >> > case HYPORT_ERROR_SOCKET_TIMEVALALLOCFAIL: >> > return "Unable to allocate the timeval structure"; >> > case HYPORT_ERROR_SOCKET_LINGERALLOCFAIL: >> > return "Unable to allocate the linger structure"; >> > case HYPORT_ERROR_SOCKET_IPMREQALLOCFAIL: >> > return "Unable to allocate the ipmreq structure"; >> > case HYPORT_ERROR_SOCKET_FDSETALLOCFAIL: >> > return "Unable to allocate the fdset structure"; >> > case HYPORT_ERROR_SOCKET_CONNECTION_REFUSED: >> > return "Connection refused"; >> > >> > default: >> > return (char *) hysock_error_message (); >> > } >> > } >> > >> > >> > Thanks, >> >> Mikhail >> >> >> >> >> >> > >> >> > Best regards, >> >> > Andrew >> >> > >> >> > >> >> > On 7/11/06, Mikhail Loenko (JIRA) <[EMAIL PROTECTED]> wrote: >> >> > > >> >> > > [ >> >> > > >> >> >> http://issues.apache.org/jira/browse/HARMONY-815?page=comments#action_12420281 >> >> >> >> >> ] >> >> > > >> >> > > Mikhail Loenko commented on HARMONY-815: >> >> > > ---------------------------------------- >> >> > > >> >> > > Hi Andrew >> >> > > >> >> > > I think it's rather dangerous: >> >> > > >> >> > > } catch (SocketException e) { >> >> > > if (ERRMSG_NONBLOKING_OUT.equals(e.getMessage())) { >> >> > > return sendCount; >> >> > > } >> >> > > throw e; >> >> > > >> >> > > Once we internationilize our code that won't work >> >> > > >> >> > > > [classlib][nio] Refine implConfigureBlocking(boolean) method of >> >> > > DatagramChannel and SocketChannel. >> >> > > > >> >> > > >> >> >> -------------------------------------------------------------------------------------------------- >> >> >> >> >> > > > >> >> > > > Key: HARMONY-815 >> >> > > > URL: http://issues.apache.org/jira/browse/HARMONY-815 >> >> > > > Project: Harmony >> >> > > > Type: Improvement >> >> > > >> >> > > > Components: Classlib >> >> > > > Reporter: Andrew Zhang >> >> > > > Assignee: Mikhail Loenko >> >> > > > Attachments: nio.diff >> >> > > > >> >> > > > Currently, Harmony >> DatagramChannel.implConfigureBlocking(boolean) >> >> does >> >> > > nothing. >> >> > > > It doesn't cause any problem of read operation because >> Harmony uses >> >> > > select+blocking read to ensure nonblocking reading. >> >> > > > But it affects write operations, although it is difficult to >> test >> >> the >> >> > > difference between blocking write and blocking write. >> >> > > > Another defect is introduced by portlib bug. As discussed on >> >> mailing >> >> > > list[1], connect_with_timeout always changes the fd to blocking >> mode >> >> after >> >> > > invocation. >> >> > > > I'll upload a patch to fix these problems. >> >> > > > Thanks! >> >> > > > Best regards, >> >> > > > Andrew >> >> > > >> >> > > -- >> >> > > This message is automatically generated by JIRA. >> >> > > - >> >> > > If you think it was sent incorrectly contact one of the >> >> administrators: >> >> > > http://issues.apache.org/jira/secure/Administrators.jspa >> >> > > - >> >> > > For more information on JIRA, see: >> >> > > http://www.atlassian.com/software/jira >> >> > > >> >> > > >> >> > >> >> > >> >> > -- >> >> > Andrew Zhang >> >> > China Software Development Lab, IBM >> >> > >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> >> >> -- >> >> Best Regards! >> >> Jimmy, Jing Lv >> China Software Development Lab, IBM >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Andrew Zhang China Software Development Lab, IBM