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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
