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:35:44 GMT
Hi Mikhail, you have agreed with it before.... :)


On 7/21/06, Mikhail Loenko <mloenko@gmail.com> wrote:
>
> I'd prefer not to throw an exception :)
>
> Thanks,
> Mikhail
>
> 2006/7/21, Andrew Zhang <zhanghuangzhu@gmail.com>:
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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