On 17.07.2006, at 14:09, Richard Liang wrote:
LvJimmy,Jing wrote:Hi Andrew: Sorry for late, but as this solution does not resolve I18N (working aound for 815 only?) , I guess we may have another way.If I understand correctly, this solution try to analysis error code in native code, throws ErrorCodeException; and java code catch this exception,get error code, and throw another exception. If so, why not just return the error code directly instead? :)Hello Jimmy,IIRC, It's SocketException that is thrown in native code, not ErrorCodeException. And we will set the ErrorCodeException as cause of the SocketException.
Yes, this is how I remember it too. The idea was to do the equivalent of the
following code in the native code (correct me if I'm wrong):
ErrorCodeException ece = new ErrorCodeException(SOME_ERROR_CODE);
throw new SocketException("Some Message", ece);
I don't think it is semantically correct to set the
ErrorCodeException as the cause
of the SocketException - the error code provides additional info, it
is not the cause
of the problem. For example, this code:
try {
ErrorCodeException ece = new ErrorCodeException(13);
throw new TestException("Something went wrong", ece);
} catch(TestException e) {
e.printStackTrace();
}
Yields the following stack trace:
net.guglhupf.test.TestException: Something went wrong
at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:7)
Caused by: Error Code 13
at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:6)
which might be confusing for some application developer so personally
I like the subclass - approach described by Andrew Zhang [1] better.
Regards,
David
[1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/
200607.mbox/%
[EMAIL PROTECTED]
I18N is anther issue, we shall have full discussion in community to mature our thoughts. :-)Do I miss something? Best regards, Richard.2006/7/14, Mikhail Loenko <[EMAIL PROTECTED]>:Hi Andrew this seems reasonable Thanks, Mikhail 2006/7/14, Andrew Zhang <[EMAIL PROTECTED]>: > Hi folks, > > I'd like to adopt Tim's suggestion to solve Harmony-815. It avoids message > comparison while keeps current luni native architecture. >> Before I upload a new patch to JIRA, I want to hear more voices from> the community. Any better suggestions? Any comments? > > Mikhail, what's your opnion? Do you think it makes sense? > > Thanks in advance! > > Best regards, > Andrew > > > On 7/14/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > 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'twant > > 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, Harmonysocket > > >> >> native > > >> >> >> code> > >> >> >> > uses messages in SocketException to identify error type.> > >> >> >> >> > >> >> >> > To avoid the confusion, two alternatives way I could imageare: > > >> >> >> >> > >> >> >> > 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 nativecode > > >> >> 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 inthe > > >> >> future. > > >> >> > > > >> >> >> > >> >> > NO. Currently, exception message thrown by native code areused 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- designnative > > >> >> 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 interfacedesign > > >> >> is more > > >> >> > suitable. > > >> >> >> > >> >> > Of course, once decision is made, I'll volunteer to revisenative > > >> >> and java > > >> >> > code. > > >> >> > > > >> >>> > >> >> Yep, I also find this strange style of return value, I doubt ifthe > > >> >> 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: harmony-dev- [EMAIL PROTECTED] > > For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED]> > > > > > > -- > 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: harmony-dev- [EMAIL PROTECTED]-- Richard Liang 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]
smime.p7s
Description: S/MIME cryptographic signature
