I like this
Tim Ellison 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'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]
>>>
>>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
