Andrew Zhang wrote: > How about design a subclass which extends from SocketException, looks like:
If you want to preserve the throwable type you could create a o.a.h.luni.ErrorCodeException that has a errorCode field set by the native, and then make that the cause of the SocketException. The calling code would then do something like: ((ErrorCodeException)ex.getCause()).getErrorCode() Just a thought. Regards, Tim > 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] >> >> > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]