Hi Mikhail, you have agreed with it before.... :)
On 7/21/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
I'd prefer not to throw an exception :)
Thanks,
Mikhail
2006/7/21, Andrew Zhang <[EMAIL PROTECTED]>:
> 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
>
>
---------------------------------------------------------------------
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
