The main reason for the exception handler in the exception handler
would be to handle an array bounds exception on the indexing op. It's
not nice to take an (unhandled) exception in an exception handler.
On Jan 20, 7:21 am, RyanMcNally wrote:
> There's been no indication that the arrays could be
There's been no indication that the arrays could be null so far, but I
guess at this point we are fully through the looking-glass so all bets
are off.
Welcome to bizarro-world, engage null-checks for your safety,
convenience and psychological integrity.
Ryan
On Jan 20, 1:07 pm, DanH wrote:
> Yo
BTW, I'm betting that the problem never reappears for those three
users.
On Jan 20, 6:38 am, RyanMcNally wrote:
> No native code I'm afraid.
>
> I've given the three users apk's with the improved exception logging,
> and so begins the waiting game...
>
> Ryan
>
> On Jan 20, 1:12 am, fadden wrote
You didn't put an exception handler around the subscript operation in
the exception handler.
On Jan 20, 6:38 am, RyanMcNally wrote:
> No native code I'm afraid.
>
> I've given the three users apk's with the improved exception logging,
> and so begins the waiting game...
>
> Ryan
>
> On Jan 20, 1:
No native code I'm afraid.
I've given the three users apk's with the improved exception logging,
and so begins the waiting game...
Ryan
On Jan 20, 1:12 am, fadden wrote:
> That is definitely strange. I can't see any reason why that exception
> would be thrown from that point.
>
> If you suspec
The values aren't identical. e.g.:
// right
frustum[ 0 ][ 0 ] = clip[ 3 ] - clip[ 0 ];
versus
// left
frustum[ 1 ][ 0 ] = clip[ 3 ] + clip[ 0 ];
Took me while to spot that myself though, this kind of s
That is definitely strange. I can't see any reason why that exception
would be thrown from that point.
If you suspect that the object has been damaged, there's an excellent
chance that your improved exception handler will throw an exception.
Or crash. Either way you will have learned something n
I'm kind of curious as to why you don't just copy the left, top, and
near planes from the right, bottom, and far planes, vs recalculating
the identical results.
On Jan 18, 7:49 am, RyanMcNally wrote:
> Hello all
>
> Hopefully someone out there can shed some light on this one, because
> it's got m
You had better wrap ".append( frustum[ i ].length );" with an
exception handler.
On Jan 19, 7:15 am, RyanMcNally wrote:
> I'll give it a shot. I've wrapped the whole method in
>
> try
> {
> ...}catch( Exception e )
>
> {
> StringBuilder b = new StringBuilder();
> b.append( "mod
What I would do is add, just ahead of the offending statement, code
that tests every reasonable possibility separately. Eg, check T for
zero and verify that you can divide a "typical" number by it (*),
access just frustum[3] and assign it to a variable, then access
element zero from there. And an
I'll give it a shot. I've wrapped the whole method in
try
{
...
}catch( Exception e )
{
StringBuilder b = new StringBuilder();
b.append( "modl.length = " ).append( modl.length );
b.append( "\nproj.length = " ).append( proj.length );
b.append( "\nfrustum.length =
The frustum object is constructed in the main UI thread, from then on
it's only touched in the rendering callback methods, which are all on
the same thread.
On Jan 19, 10:46 am, Kostya Vasilyev wrote:
> I would try moving the initialization of "frustum" into the constructor,
> and add log stateme
Ok its statically verifiable. I still suggest try catching the exception and
logging diagnostics.
On Jan 19, 2011 2:35 AM, "RyanMcNally" wrote:
> Does anyone have any suggestions on what diagnostics to add? The code
> is statically verifiable not to throw AIOOBEs, so I've got no idea
> what to che
I would try moving the initialization of "frustum" into the constructor,
and add log statements for array size(s) in the method.
BTW, you said, no threading - but don't you have a separate rendering
thread?
-- Kostya
19.01.2011 13:35, RyanMcNally пишет:
Does anyone have any suggestions on w
On Jan 19, 8:26 am, mort wrote:
> Only a blind shot: Did you check whether another instance of frustrum
> is used? Like e.g. an accidental "float[][] frustrum = ..." in the
> function or maybe even an if block or something similar, so a local
> instance is used instead of the class member, parame
Does anyone have any suggestions on what diagnostics to add? The code
is statically verifiable not to throw AIOOBEs, so I've got no idea
what to check for at runtime.
Given that there is no threading, the arrays are defined exactly once,
and the same indices are successfully written to 8 lines ear
Unfortunately, division by zero does not raise an exception at all -
you just get infinity as a result.
I would be utterly appalled if there was anything remotely fuzzy about
how exceptions are raised, but it would certainly be an explanation
for this situation
Cheers!
On Jan 18, 9:51 pm, DanH wr
(1) Yeah, it would have been *fascinating* to see the value of the
offending index
(2) Glad someone agrees - self-doubt is my default mode in cases like
this ;-)
(3) Threading is usually the culprit for weird errors like this.
Unfortunately, there's no threading happening here. Also, as the
frust
Only a blind shot: Did you check whether another instance of frustrum
is used? Like e.g. an accidental "float[][] frustrum = ..." in the
function or maybe even an if block or something similar, so a local
instance is used instead of the class member, parameter, or whatever
was intented.
However, I
I suggest catching the AIOBE and adding your own diagnostics, via a toast,
log, or analytics code.
--
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
I'm betting you're getting a divide-by-zero and the wrong exception is
being raised, due to near proximity of the two tests and some likely
fuzzy machine level exception resolution logic.
On Jan 18, 7:49 am, RyanMcNally wrote:
> Hello all
>
> Hopefully someone out there can shed some light on thi
(1) I agree that more core exceptions like AIOOBE should give better
diagnostics, at the (rare) expense of the StringBuilder work to
do it.
(2) If multiple people are seeing it on the same line number, then
it's
likely a real problem. Now to figure out how to reproduce it.
(3) Any thr
22 matches
Mail list logo
