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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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:
[EMAIL PROTECTED]
>> > > For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> > >
>> > >
>> >
>> >
>> > --
>> >
>> > Andrew Zhang
>> > China Software Development Lab, IBM
>> >
>>
>>
>>
>> --
>> Andrew Zhang
>> China Software Development Lab, IBM
>>
>
>
>

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Andrew Zhang
China Software Development Lab, IBM

Reply via email to