THINGS I CHECKED For recursive writeBackwards: --empty string returns nothing. --string of one character works --string of more characters works --numbers and punction aren't a problem For iterative writeBackwards: --empty string returns nothing. --string of one character works --string of more characters works --numbers and punction aren't a problem For recursive power: --empty strings entered throw an exception --anything non-number throws an exception --negative number in base is not a problem --negative number in the exponent originally caused an endless loop; now throws an exception. (see below for discussion) --zero base works (= 0) --zero exponent works (= 1) --big numbers mean that the result is bigger than int can hold. This is likely common with exponential computations. Changed to a long. --still very easy to go over. Also, very interesting to note that any large exponent with a base 10 returns 0. Must be something with how it's stored? Odd. Don't know how to fix that, so left it. For iterative power: --same tests made as with recursive power For recursive binary search: --space or "," works as a delimiter, regardless of spacing or number used --other anamolous input throws an exception --empty array works --array of one works, both finding and not finding --larger arrays initially did not work. Fixed midpoint computation from "(first - last)/2" to "(first + last)/2", which works. --unordered arrays may or may not work. (Oh, what to do here? Check for them? Left it as is.) For iterative binary search: --same tests and changes made as recurisve binarySearch For recursive kthSmallest: --an array of 0 size throws an exception --a k greater than the size of the array throws an exception --a k of 0 or less throws an exception --array of size 1 works --array of size 2 did not work; now does --arrays of larger sizes work --problem with k = size of array; futher testing revealed other buggy things; now all fixed (it was a problem with element removal) --array contains more than one / all the same values works --array containing negative integers or zero works For iterative kthSmallest --all the same test as for recursive version: passed Comments: I was working on testing all my methods and found that the recursive power() method ran into an endless loop when the exponent was a negative integer. This was a cause for a lot of thought. (Luckily, I had already passed the assignment submission time, so I could sit back and ponder this a bit). I didn't just want to return some arbitrary number, like -1. If someone passed me a negative exponent, they were probably ready to just take the response and run with it, expecting the result to be correct. So I thought maybe I should have a try/catch within the method to print out a message that there was invalid input. However, maybe they wouldn't catch the error on the screen. And this seemed rather tacky since I still had to return some arbitrary, "incorrect" integer at the end of the method. That wouldn't work. I could catch the exception myself and query the user to fix the input. But I don't know how this method might be called. In all likelihood (in a real application), the user has no clue at all what the input was. On the other hand, it seemed troublesome to force someone to always code to catch an exception that would not occur unless they actively violated the initial parameters of my method. What's the use of having parameters or a client/server contract if I still feel obligated to filter for lousy input? Yet submitting a negative exponent is probably the most likely error to happen with this method. And, if I don't throw an exception, whoever uses my method may have to check their input before they can use my method. Integer.parseInt()'s exception throwing is handy, and a good example of this. I'd rather have to catch an exception than run tests on all my strings to see if they'll parse properly. This exception throwings seems to depend on what they're doing, whether their input is going to be pretty clean and they've paid attention to the docs, or whether they too are getting user input that might be flawed. In the end, I threw an InvalidInputException (my own devising; couldn't find an suitable exisiting exception). What's a good guideline for future coding for how much we should rely on the client/server contract ideal, and how much we should be filtering input? For example, should we be testing whether binarySearch really gets an ordered list? (NOTE: comments posted on WebCT discussion board.) Author: Zach Tomaszewski For: ICS211, Fall 2001