why would you throw runtime exception instead of returning false? lmao

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.

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

how do i add this to  my bot so it works?

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.