harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Date Fri, 21 Jul 2006 10:17:29 GMT
Dear all,

When I investigated the code, I found there was only one error code which
needs to be handled.

It's HYPORT_ERROR_SOCKET_WOULDBLOCK.

The better thing I discovered is that after catching this exception, then
handle routine looks like:

catch( the exception ) {
// it should return null if the data is not ready currently.
return null;
}

No exception is re-thrown!

I examined the code of luni module carefully, and found it never throws
a SocketException by
throwJavaNetSocketException(....,HYPORT_ERROR_SOCKET_WOULDBLOCK).   Please
correct me if I'm wrong. :) I have tried my best to examine the luni code.

Therefore, either using subexception or SocketException with cause is a
totally internal thing for NIO module and it doesn't affect luni module.

For current situation, which one would everyone prefer to? no confusing
stack trace problem, no compatibility problem...

Thank you for your suggestions and comments!

Best regards,
Andrew



On 7/21/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>
> Andrew Zhang wrote:
> > Hi everyone,
> >
> > I have one more question:
> >
> > Which exception should be thrown whose error code is unused?
> >
> > Let's consider native throwJavaNetSocketException quoted from nethelp.c:
> >   void
> >   throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
> >   {
> >    jclass aClass;
> >    char *errorMessage = netLookupErrorString (env, errorNumber);
> >    aClass = (*env)-FindClass (env, "java/net/SocketException");
> >    if (0 == aClass)
> >      {
> >        return;
> >      }
> >    (*env)-ThrowNew (env, aClass, errorMessage);
> >   }
> >
> > There are only several error numbers need to be handled in javal
> classlib.
> > For most of them, throw java.net.SocketException is enough.
> >
> > So shall we throw subclass of SocketException for several special error
> > codes or for all error codes? Suggestions?
>
> Just the ones that need it.
>
> > What's the name of subclass of SocketException? Need your suggestions.
> :)
>
> I never thought it should be a subclass anyway, so I'm not going to
> suggest a name <humpf>  :-)
>
> <sidebar>ever thought about stuffing the errno into a private/default
> vis. variable on SocketException?</sidebar>
>
> Regards,
> Tim
>
> > Thanks!
> > Best regards,
> >
> > On 7/19/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> >>
> >>  Hi everyone,
> >>
> >> If no one objects, I'd like to throw subclass of SocketException in
> >> native
> >> code to fix this problem. Any suggestions, please kindly let me know.
> >> Thanks!
> >>
> >>
> >>  On 7/18/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
> >> >
> >> >  Seems most people prefer subclass to SocketException with
> >> > ErrorCodeException cause.
> >> >
> >> > Does anyone prefer the latter? or both are acceptable?
> >> >
> >> > I think we'd better made an agreement about this issue.
> >> >
> >> > Mikhail, how do you think about it? Which one do you prefer? :) I'll
> >> fix
> >> > Harmony-815 once decision is made.
> >> >
> >> > Thanks!
> >> >
> >> >
> >> >  On 7/18/06, Alexey Varlamov < alexey.v.varlamov@gmail.com> wrote:
> >> > >
> >> > > IMHO, throwing a subclass certainly fits to specification and can
> >> > > hardly break compatibility with RI. I consider this is the proper
> >> > > workaround for now.
> >> > > Just my $0.02 :)
> >> > >
> >> > > --
> >> > > Alexey Varlamov
> >> > > >
> >> > > > In this case, I guess if we set the cause to null when catching
> the
> >> > > > SocketException will properly solve the problem. However it seems
> >> > > > difficult as Throwable.initCause() can be called only once.
> >> > > >
> >> > > > If throwing a subclass may also break compatibility guideline,
I
> >> > > still
> >> > > > suggest return value, though it may break the current
> >> > > > infrastructure(currently, all errors throw exception), it is
> still
> >> > > easy
> >> > > > to deal with, only some of operation, read/write, require a
> little
> >> > > > change, and we no longer need "try...catch" in Java code
> >> > > >
> >> > > > BTW, I find the code shall also deal with InterruptIOException.
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> > > To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> >> > > For additional commands, e-mail:
> >> harmony-dev-help@incubator.apache.org
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> >
> >> > Andrew Zhang
> >> > China Software Development Lab, IBM
> >> >
> >>
> >>
> >>
> >> --
> >> Andrew Zhang
> >> China Software Development Lab, IBM
> >>
> >
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Andrew Zhang
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message