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]
