-1

I have tried just about everything I know to fix this problem but nothing is coming clear to me. Below is the code in a class that will return the thread name. Now if the thread's name matches the one provided to this method, then it will return the index of that ArrayList. Problem is, the bool is true however it never seems to enter the if statement. just moves around it and instead returns ERROR_NOTFOUND symbol. This would imply that the program ignores the contents of the if statement and moves on to the second return, completely bypassing the chance of ever hitting the first return. Thus never reaching 'return i;'....

I have debugged this many times to no avail with little to no answers as to why. Feel free to run the arbitrary code and try for oneself. I have completely stripped the project down to this and still nothing. Yet applying the answer i have below works.

My thinking is it has something to do with the keywords used. Also, in my digging for an answer, I'm yet to come across anything that helps. So let me know if there is an answer somewhere so that I may be able to better my searching skills.

    private static int searchThread(ArrayList<Thread> threads, String name) {
    int i;
    for (i = 0; i < threads.size(); i++) {
        Thread thread = threads.get(i);
        String temp = thread.getName();
        Boolean bool = temp.equals(name);
        if (bool) {
            return i;
        }
    }
    return ERROR_NOTFOUND;
}

EDIT: to further the details, i have debugged this code. I have also try to clean and rebuild, thinking that was the problem, but neither helped. So it is a problem with my logic or lack of understanding the true impacts of either the keywords used, UI Thread used, or something else unbeknownst to me.. Any ways the section of code runs on the UI Thread which has never been a problem until now? The if statement is NOT ignored with "return i" is replaced with "return 1". It will then return 1 successfully.

Mr.Invisible
  • 167
  • 2
  • 10
  • 6
    How do you know `bool` is true? Did you debug it? Did you print it out? Are there any `threads` at all? – tima Aug 24 '17 at 19:48
  • 1) are you logging the `bool` to verify it's true? 2) is `searchThread` ran on the UI thread? 3) why not `volatile boolean bool = temp.equals(name);` ? – Shark Aug 24 '17 at 19:48
  • 3
    [What is a debugger and how can it help me diagnose problems?](https://stackoverflow.com/q/25385173/5221149) – Andreas Aug 24 '17 at 19:49
  • 1
    It wont enter the loop if your array of threads is empty – C0D3LIC1OU5 Aug 24 '17 at 19:50
  • whats your input to `searchThread`? – Naman Aug 24 '17 at 19:54
  • i have debugged this many times, bool becomes true the second pass but the if statement just ignores the bool regardless of states. – Mr.Invisible Aug 24 '17 at 20:14
  • @nullpointer my input to searchThread is int i = searchThread(threads, name); – Mr.Invisible Aug 24 '17 at 20:18
  • @Mr.Invisible whats `thread` thre? share the complete implementation – Naman Aug 24 '17 at 20:20
  • its just a class that extends a typical android Thread.. not much to it. Threads is the reference to the ArrayList of multiple threads' – Mr.Invisible Aug 24 '17 at 20:28
  • If you want to search thread, you can search byId() method instead of comparing the name which is always better than comparing string – Farmaan Elahi Aug 24 '17 at 20:43
  • @ Framaan Elahi This would be nice except i need to know other features of my extended threads. This doesn't allow detecting similar or same threads. – Mr.Invisible Aug 24 '17 at 20:56
  • What exactly do you mean by "it never seems to enter the if statement. just moves around it"? Are you talking about your debugger? What was the actual returned value, outside of that method, when that happened? Did you check after the calling point? – Mike M. Aug 24 '17 at 21:53
  • Btw, I'm only asking because you stated "if anyone can point out why 'i' was unable to be returned in the first attempt, i'd love to know". I believe I know why. – Mike M. Aug 24 '17 at 23:45
  • @Mike M. If you read the above question, I stated that "it just moves around it" and just after that mention it returns ERROR_NOTFOUND. this would imply that the program ignores the contents of the if statement and moves on to the second return, completely bypassing the chance of ever hitting the first return. Thus never reaching 'return I;'.... As mentioned many time before, I have debugged this many times to no avail with little to no answers as to why. Feel free to run the arbitrary code and try for yourself. I have completely stripped the project down to this and still nothing. – Mr.Invisible Aug 25 '17 at 04:46
  • Yet apply the answer that I have below, and it now works... My question is why the first approach fails? – Mr.Invisible Aug 25 '17 at 04:49
  • I'm trying to establish with certainty that you're talking about the debugger's behavior; that the line it's tracking is what "moves around it". You never specifically mention that in the question, and people here use all sorts of different euphemisms to describe their code's behavior. – Mike M. Aug 25 '17 at 04:52
  • Apologies, yes I was referring to how the debugger reacted to the code as well as the failure of the code without the debugger. – Mr.Invisible Aug 25 '17 at 04:56
  • 1
    Well, unless there's some unseen threading issue, that conditional really shouldn't fail, and the actual return from `searchThread()` should be correct outside the method. Anyway, the debugger has always had issues tracing multiple return paths in a method: http://stackoverflow.com/questions/21805868. When you changed it to a single `return`, that was resolved. – Mike M. Aug 25 '17 at 05:07
  • Holy crap! Learned something new! Anyways, looks like that might be the culprit. But FYI, the code never returned the correct value anyways. Never would have guessed the dx compiler... Thank you for pointing this out! – Mr.Invisible Aug 25 '17 at 05:14
  • Yeah, that's what I meant by unseen issues. Your two snippets are equivalent, and the one in the answer is basically what the dexer would turn the other into. If you didn't change anything else in applying your fix, the first thing that jumps to mind is just off timing, or maybe the debugger isn't set to pause all threads on the breakpoints in that method. Anyhoo, just wanted to point ya toward that post. Later. – Mike M. Aug 25 '17 at 05:31

2 Answers2

1

the scenario you have described is not possible.

return i

means that some number must be returned.

there are two possible explanations:

1)you didn't check the "bool" status , and it's false.

2)the thread size is zero , so the program does not enter the loop

  • i did check bool status that is why there is a if statement... and bool does become true. its just ignored for some other reason. – Mr.Invisible Aug 24 '17 at 20:15
  • i meant that you didn't check the bool status in the debugging mode and the thread size in the debugging mode – Elad Shamailov Aug 24 '17 at 20:39
  • i did check and everything was working correctly except for returning 'i'. it kept skipping over on down to the other return. – Mr.Invisible Aug 24 '17 at 20:52
  • Nothing here explains anything. Values and variables are correct and the debugger is fine and working, the code was cleaned and rebuilt. The debugger simply gets to the if statement and on the next move into instruction despite bool being true, skips past to the last return to ultimately provide ERROR_NOTFOUND instead of going into the statement and returning i. – Mr.Invisible Aug 25 '17 at 05:11
1

So i appeared to have fixed my own problem but i'm still puzzled as to why the first attempt was unable to return 'i' as 'i' was able to be seen and edited in the for loop as well as in the if statement.

Anyways, below is the code used to get it working. Creating an addition int variable initialized to the 'ERROR_NOTFOUND' and once the thread was found change that to the variable of 'i'. Just found a different way of looking at the problem.

Again, if anyone can point out why 'i' was unable to be returned in the first attempt, i'd love to know as it just seems so odd..

EDIT: not so puzzled any more. Looks like it's a compiler & debugger issue after all. Link for more details. http://stackoverflow.com/questions/21805868

private static int searchThread(ArrayList<Thread> threads, String name) {
    int status = ERROR_NOTFOUND;
    for (int i = 0; i < threads.size(); i++) {
        Thread thread = threads.get(i);
        String temp = thread.getName();
        Boolean bool = temp.equals(name);
        if (bool) {
            status = i;
        }
    }
    return status;
}

My if statement has since been shortened to

if (thread.getName().equals(name)) {
Mr.Invisible
  • 167
  • 2
  • 10