XavierM Posted October 20, 2013 Posted October 20, 2013 why would you throw runtime exception instead of returning false? lmao
liverare Posted October 20, 2013 Posted October 20, 2013 why would you throw runtime exception instead of returning false? lmao Lol, you caught me there! I initially was going to return if ((on && i == 1) || (!on && i == 0)) as a bool itself rather than having the selector. This would have meant that returning false, whether the Setting menu wouldn't open or whether the Setting interface isn't valid, would have worked against the final conclusion: checking to see whether we interacted with the 'run' button and got the desired outcome. However, I strayed from that idea and decided to shove that condition in a selector and return true so I could implement a safer, conditional recursion. I decided to throw Runtime exceptions to allow developers to examine the source of the problem since, if you create a bool method that handles every problem by just returning false, there's no way to examine the source of the problem without debugging. <embarrassment> ...But I slacked on the new revision and, even though this is a bool method, at no point does it return false. </embarrassment> } else { j.getChild(34).interact(); boolean run = setRun(on); if (!run) throw new RuntimeException("Run toggling failed"); else return true; } to: } else { return j.getChild(34).interact() && setRun(on); /*setRun should return true from the first selector choice. If we didn't interact with the 'run' button, it'll return false before recurring the same method. } That will provide a false returnable, and I don't have to remove any other throwables.
Mr Asshole Posted October 20, 2013 Posted October 20, 2013 why would you throw runtime exception instead of returning false? lmao Lol, you caught me there! I initially was going to return if ((on && i == 1) || (!on && i == 0)) as a bool itself rather than having the selector. This would have meant that returning false, whether the Setting menu wouldn't open or whether the Setting interface isn't valid, would have worked against the final conclusion: checking to see whether we interacted with the 'run' button and got the desired outcome. However, I strayed from that idea and decided to shove that condition in a selector and return true so I could implement a safer, conditional recursion. I decided to throw Runtime exceptions to allow developers to examine the source of the problem since, if you create a bool method that handles every problem by just returning false, there's no way to examine the source of the problem without debugging. <embarrassment> ...But I slacked on the new revision and, even though this is a bool method, at no point does it return false. </embarrassment> } else { j.getChild(34).interact(); boolean run = setRun(on); if (!run) throw new RuntimeException("Run toggling failed"); else return true; }to:} else { return j.getChild(34).interact() && setRun(on);/*setRun should return true from the first selector choice. If we didn't interact with the 'run' button, it'll return false before recurring the same method. }That will provide a false returnable, and I don't have to remove any other throwables. You make everything more complicated :P
Assume Posted November 20, 2013 Posted November 20, 2013 I was wrong, this shitty shit is even worse than that shitty shit you guys posted in the isInCombat thread. I doubt my expectations of an OSBot programmer can drop much more.