harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: I18N on native (was:Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Date Thu, 13 Jul 2006 06:42:49 GMT
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 for JIT guys to comment.

Thanks,
Mikhail

2006/7/13, Paulex Yang <paulex.yang@gmail.com>:
> 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 program
> generally return error codes and use output parameter if necessary,
> while Java codes generally separate normal return value and exceptional
> case. JNI is combined by Java and C, so there must be one side to
> violate the convention.
>
> Throwing exception in native codes makes the codes hard to understand or
> maintain, while returning error codes may introduce one more time error
> code conversions[1], further, sometimes not only error code but the
> error message generated by OS is useful.
>
> [1]check out the stack below, there are several error codes set needed:
> Java codes-->platform indepdent native codes-->portlib codes-->system call
> 1. system call error codes, which is platform dependent
> 2. portlib error codes, which is platform independent
> 3. Java error codes, which is returned by JNI methods to Java,  so it
> needs to be defined in in Java codes(i.e. in generated JNI header files)
> 4. Java Exception class
> > 2) don't parse exception messages in the code (use subclasses of
> > exceptions
> > when necessary)
> Agree, String comparison is not good in many ways.
> >
> > Thanks,
> > Mikhail
> >
> > 2006/7/13, Andrew Zhang <zhanghuangzhu@gmail.com>:
> >> On 7/13/06, Jimmy, Jing Lv <firepure@gmail.com> 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) make native code return error code instead of throw exceptions, and
> >> > let Java code deal with these errors. This seems pretty good, and also
> >> > resolve such problems like 815, but require much more effort to
> >> refactor
> >> > all native and Java codes. What's more, as some native methods do not
> >> > return an integer at all, we may add an output parameter to them, at
> >> > least for network-related luni/nio, there are about 10 methods like
> >> this.
> >>
> >>
> >> May we add an output parameter "errorCode" in each method.
> >>
> >> 2) As it is still easy for native code to call Java code, so rewrite
> >> > error-message-lookup native method to lookup internationalized
> >> message,
> >> > e.g., call MsgUtil.getString(). This refactor may be easy, but to
> >> > JIRA-815 and other message-dependent Java code, it do no help. So it
> >> > still requires other refactoring, e.g., return error code in some
> >> > situation like suggested in (1).
> >> >
> >> > Another solution can be: catch exceptions on Java code, replace its
> >> > message, and throw out again, this may be too ugly, so I do not
> >> suggest
> >> > so.
> >> >
> >> > Any suggestions? Thanks!
> >> >
> >> > --
> >> >
> >> > Best Regards!
> >> >
> >> > Jimmy, Jing Lv
> >> > China Software Development Lab, IBM
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> ---------------------------------------------------------------------
> 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
>
>

---------------------------------------------------------------------
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


Mime
View raw message