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 native
whenever possible.
I think impossible is nothing. :) All exception thrown by native code can be replaced by error code. Are there any exceptions? Of course, VM is not in the scope of this discussion.
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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]>: > >> 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) 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: [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] > > > > > > > -- > Paulex Yang > 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] > > --------------------------------------------------------------------- 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
