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
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
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
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;
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 =
Alexey Varlamov 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 :)
Thanks Alexey, I have no objection if it does not break compatibility
guideline :)
--
Alexey
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
2006/7/18, Andrew Zhang [EMAIL PROTECTED]:
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
LvJimmy,Jing wrote:
Hi Andrew:
Sorry for late, but as this solution does not resolve I18N (working
aound for 815 only?) , I guess we may have another way.
If I understand correctly, this solution try to analysis error code in
native code, throws ErrorCodeException; and java code catch this
David Tanzer wrote:
On 17.07.2006, at 14:09, Richard Liang wrote:
LvJimmy,Jing wrote:
Hi Andrew:
Sorry for late, but as this solution does not resolve I18N (working
aound for 815 only?) , I guess we may have another way.
If I understand correctly, this solution try to analysis error
On 7/17/06, David Tanzer [EMAIL PROTECTED] wrote:
On 17.07.2006, at 14:09, Richard Liang wrote:
LvJimmy,Jing wrote:
Hi Andrew:
Sorry for late, but as this solution does not resolve I18N (working
aound for 815 only?) , I guess we may have another way.
If I understand correctly, this
David Tanzer wrote:
On 17.07.2006, at 14:09, Richard Liang wrote:
LvJimmy,Jing wrote:
Hi Andrew:
Sorry for late, but as this solution does not resolve I18N (working
aound for 815 only?) , I guess we may have another way.
If I understand correctly, this solution try to analysis error code
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
Hi Andrew:
Sorry for late, but as this solution does not resolve I18N (working
aound for 815 only?) , I guess we may have another way.
If I understand correctly, this solution try to analysis error code in
native code, throws ErrorCodeException; and java code catch this exception,
get error
Hi Vladimir,
Where exceptions should be thrown is a big question in this thread. Native
code or Java code or mixed?
Shall we avoid throwing all exceptions in Harmony native code?
If all exceptions are thrown in java code, there is no need to involve any
other I18N utilities (i.e. log4cXXX).
Mikhail Loenko wrote:
I suggest that we:
1) avoid throwing exceptions from native code
I have no strong feelings yet which is better, to throw Exception in
native codes directly or always to return error codes to Java. There are
different styles in Java and C programming on error handling, C
On 7/13/06, Andrew Zhang [EMAIL PROTECTED] wrote:
Hi Vladimir,
Where exceptions should be thrown is a big question in this thread. Native
code or Java code or mixed?
Yes, I'm aware about this. However I'd prefer to have other subject for this
thread :-).
Thanks,
Vladimir.
Shall we avoid
Minor note:
I havn't insisted that we *always* return error code rather than throw
Exception,
instead I suggest that we avoid throwing exceptions from native
whenever possible.
I thought that native calls that don't throw exceptions might be optimized
by JIT. But it's only a guess, I leave it
On 7/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Minor note:
I havn't insisted that we *always* return error code rather than throw
Exception,
AFAIK, luni and nio modules always throw exception rather than return error
code.
instead I suggest that we avoid throwing exceptions from
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the cause of the SocketException.
The
I like this
Tim Ellison wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks
like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks
like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then
Andrew Zhang wrote:
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks
like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by
On 7/14/06, Richard Liang [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException, looks
like:
If you want to preserve the throwable type you could create a
Hi folks,
I'd like to adopt Tim's suggestion to solve Harmony-815. It avoids message
comparison while keeps current luni native architecture.
Before I upload a new patch to JIRA, I want to hear more voices from
the community. Any better suggestions? Any comments?
Mikhail, what's your opnion?
Hi Andrew
this seems reasonable
Thanks,
Mikhail
2006/7/14, Andrew Zhang [EMAIL PROTECTED]:
Hi folks,
I'd like to adopt Tim's suggestion to solve Harmony-815. It avoids message
comparison while keeps current luni native architecture.
Before I upload a new patch to JIRA, I want to hear more
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony socket native
code
uses messages in
Andrew Zhang wrote:
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony socket native
code
uses
-1 for applying the patch
Applying this patch means creating a hidden problem
Thanks,
Mikhail
2006/7/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Andrew Zhang wrote:
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew
Hello Mikhail,
I think it's about native source architecture design. The patch is made
based on current native source code.
Of course, Ihow to design a native and java interface is a good topi for
discussion on mailing list.
But, could you please suggest what shall I do next? Change all native
Hi Mikhail:
This applying is not creating a hidden problem, as this code exists
already. If I remember correctly, the last patch to DatagramChannelImpl
removes this code, however later find it still necessary. And I remember
SocketChannel also contain such code similar to this.
I see no
I agree with the reason why (I think I understand it - you don't want to
rely on the result of getMessage() to determine the problem...)
Could you wrap the socket exception to carry a simple integer error code?
geir
Mikhail Loenko wrote:
-1 for applying the patch
Applying this patch means
Hello Geir,
I also mention this solution as option.1.
But it has to be portable error code, which should be defined in portlib.
Thanks!
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I agree with the reason why (I think I understand it - you don't want to
rely on the result of
Hi:
I'd like to raise the topic on I18N of native code. As discussed
about patch-815, we found there are exceptions thrown by native code
with un-internationalized error message. To resolve this problem, there
may be two solutions:
1) make native code return error code instead of throw
On 7/13/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote:
Hi:
I'd like to raise the topic on I18N of native code. As discussed
about patch-815, we found there are exceptions thrown by native code
with un-internationalized error message.
To resolve this problem, there
may be two solutions:
I suggest that we:
1) avoid throwing exceptions from native code
2) don't parse exception messages in the code (use subclasses of exceptions
when necessary)
Thanks,
Mikhail
2006/7/13, Andrew Zhang [EMAIL PROTECTED]:
On 7/13/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote:
Hi:
I'd like to
Seems workable, but the exception messages thrown by native codes still
need to be internationalized, you may want to invoke Msg.getString() to
get the localized message as what Java codes do, but of course this is
another issue.
Andrew Zhang wrote:
How about design a subclass which extends
On 7/13/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote:
Hi:
I'd like to raise the topic on I18N of native code. As discussed
about patch-815, we found there are exceptions thrown by native code
with un-internationalized error message. To resolve this problem, there
may be two solutions:
1)
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony socket native code
uses messages in SocketException to identify error type.
To avoid the confusion, two alternatives way I could image are:
1. Native code returns platform-independent error code.
2.
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony socket native code
uses messages in SocketException to identify error type.
To avoid the confusion, two alternatives way I could image are:
1. Native code
41 matches
Mail list logo
