[android-developers] Re: Exceptions in user libraries

That sounds like a problem related to native methods (or, more likely,
a "feechur"). When the exception percolated to the native method
boundary it was converted into a return code. Some systems do this
more elegantly than others.

On Jan 23, 7:05 pm, Steve <rockthesm...@gmail.com> wrote:
> Hi there,
>
> I am developing for Android from Eclipse running on the Windows OS. As
> I have multiple projects that share certain parts of code, I have made
> said code into an Android library, and then reference said libraries
> to the projects. I am doing this by using the 'Library' panel under
> the 'Android' section (when you right click -> Properties on a
> project). The library projects have 'Is Library' ticked, and the main
> projects add the library projects.
>
> In terms of being able to build and run, this appears to work. However
> I have run into two problems, one more serious than the other:
>
> 1. When I make a change to the source for a library, when I ask
> Eclipse to run/debug it doesn't pick up the change. I have to instead
> refresh (F5) the main project - this appears to correctly pull in
> dependencies (incidentally, I also have to do this if I make a change
> to native code using the NDK and rebuild the resulting .so file). Is
> there a way to force these sorts of dependency checks to automatically
> be taken into consideration when I debug run? I have got reasonably
> used to refreshing when running, but it is somewhat easy to loose
> track of what source file you are editing, and forgetting it is one in
> a library that means a refresh is required. It can result in wasted
> debug sessions when you are running unexpected code!
>
> 2. My more serious problem is: when an unhandled exception is thrown
> in library code, it doesn't tell me about the exception in an easy
> way. For example, today I had an exception raised, and it reported to
> me that it was coming from the GLThread.run method, from
> GLSurfaceView.java - so I went through the various hoops for getting
> the source code for Android onto my PC, so I could view
> GLSurfaceView.java, and saw the exception was coming from
> 'guardedRun', which in turn was calling 'onDrawFrame', which in turn
> called out to my native render + update function (using the NDK),
> which in turn called back into my Java code to load some music, and
> *that* code then went onto attempt to access an array with an invalid
> index. None of this was shown in the callstack (only GLThread.run
> appeared there), instead I had to make my own version of GLSurfaceView
> that had some try/catch statements that caught the exception, and gave
> me a callstack of where the problem lies by using e.printStackTrace().
> Once I had the callstack, I was able to fix up the offending code. I
> don't remember having this problem before I made my code into a
> library - I thought previously exceptions were getting caught much
> earlier on. I am simply not remembering correctly? Or is there some
> limitation when using libraries? If I am not remembering correctly,
> clearly I just need to wrap my Java code that is being called from my
> native code with try/catch/print exception blocks so I can avoid this
> problem again.
>
> I look forward to your responses,
>
> Steve

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en