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()
Great! It includes error code, meanwhile, keeps all the information of the
original exception.
One more question: How to I18N exception message in this way? Leave it alone
or do it in native code?
Thanks!
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]
--
Andrew Zhang
China Software Development Lab, IBM
