harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@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 07:07:05 GMT
On 7/13/06, Mikhail Loenko <mloenko@gmail.com> 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 <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
>
>


-- 
Andrew Zhang
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message