harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@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:26:28 GMT
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


Mime
View raw message