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 Thu, 20 Jul 2006 00:04:12 GMT
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?

What's the name of subclass of SocketException? Need your suggestions. :)

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
>



-- 
Andrew Zhang
China Software Development Lab, IBM

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