true, but at least in my case, leaking a pointer per exception is not that
big a deal.
i have to contact a team i work with that actually generates the JCC
interface, and they're located in Norway...
On Tue, Nov 28, 2017 at 4:48 PM, Andi Vajda <va...@apache.org> wrote:
>
> > On Nov 28, 2017, at 16:09, William Schilp <william.sch...@ansys.com>
> wrote:
> >
> > i sort of agree with you. throwing an object through a DLL boundary may
> be
> > problematic due to memory allocation/deallocation. but in this case, it's
> > throwing a pointer (_jthrowable*), which is pretty much the same as
> > throwing an int...
>
> Until you free the pointer or something...
> But you didn’t answer my question ?
>
> Andi..
>
> >
> >
> >> On Tue, Nov 28, 2017 at 12:42 PM, Andi Vajda <va...@apache.org> wrote:
> >>
> >>
> >>> On Nov 28, 2017, at 11:27, William Schilp <william.sch...@ansys.com>
> >> wrote:
> >>>
> >>> i'm using JCC in a rather large project where a C++ interface drives a
> >> java
> >>> application through the JCC interface. the java application makes
> >>> considerable use of exceptions (as it should) and the C++ interface
> needs
> >>> to catch the various exceptions and perform various actions based on
> the
> >>> exception thrown. unfortunately i have to use visual studio to compile
> >> the
> >>> C++ interface as well as the JCC interface. with vs2012 i was getting
> >>> random problems when trying to extract information from an exception
> >> thrown
> >>> by the java application as ExceptionOccurred() would randomly return
> >> NULL..
> >>> with vs2015, ExceptionOccurred() always returns NULL. the basic flow
> was
> >>> this:
> >>>
> >>> // setup the JNI interface, which returns a pointer to the JNIenv
> >>> JNIEnv* jniEnv = setupJNIenv();
> >>>
> >>> _jthrowable* jException = NULL;
> >>> try
> >>> {
> >>> <call something via JCC which fails throwing an exception in the java
> >>> code>;
> >>> }
> >>> catch(_EXC_JAVA jErr);
> >>> {
> >>> _jthrowable* jException = jniEnv->ExceptionOccurred(); <--- in vs2012
> >>> this randomly returns NULL for exceptions that are caught
> >>> }
> >>> if(jException != NULL)
> >>> {
> >>> <do something for exception>
> >>>
> >>> as noted, ExceptionOccurred() would randomly return NULL when built
> with
> >>> vs2012, this was annoying but only happened on windows 10 machines.
> we've
> >>> moved to vs2015, and now ExceptionOccurred() always returns NULL. in
> >>> debugging this issue i put a break in JCCEnv::reportException():
> >>>
> >>> void JCCEnv::reportException() const
> >>> {
> >>> JNIEnv *vm_env = get_vm_env();
> >>> jthrowable throwable = vm_env->ExceptionOccurred(); <---- throwable
> is
> >>> not NULL here...
> >>>
> >>> if (throwable)
> >>> {
> >>> if (!env->handlers)
> >>> vm_env->ExceptionDescribe();
> >>>
> >>> // python code removed
> >>> }
> >>> throw _EXC_JAVA;
> >>> }
> >>>
> >>> when i break at vm_env->ExceptionOccurred() it returns a non-NULL
> >>> throwable. then when i break in my catch block: catch(_EXC_JAVA)...
> >>> and look at the return value for ExceptionOccurred() it returns NULL.
> for
> >>> whatever reason, between the break in reportException() at
> >>> ExceptionOccurred() and my catch block, whatever is supposed to store
> the
> >>> jthrowable pointer gets set to NULL.
> >>> so i made a change to the throw _EXC_JAVA to throw a copy of the
> >> jthrowable
> >>> as such:
> >>>
> >>> throw jthrowable;
> >>>
> >>> and then catch the jthrowable in my interface. this appears to work as
> >> the
> >>> jthrowable is now non-NULL and i'm able to extract the actual contents
> of
> >>> the exception.
> >>>
> >>> my questions:
> >>>
> >>> 1. Why does JCCEnv::reportException() throw an int instead of the
> >>> jthrowable?
> >>
> >> Because throwing object exceptions across DLL boundaries is fraught.
> Using
> >> int is recommended.
> >>
> >>> 2. do you have any idea why the return of JCCEnv::ExceptionOccurred()
> >> would
> >>> return non-NULL in reportException() and then in a later catch block
> >> return
> >>> NULL?
> >>
> >> If I remember correctly, the exception support requires JCC to be built
> in
> >> shared mode.
> >> Did you build it this way ?
> >>
> >> Andi..
> >>
> >>
> >>
>
>
