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 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.
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]
