In addition; I have all the operations written that I need except for one final one. And that is clear(). clear() is meant to empty the array, essentially it is a popAll() method. Then all I need to do is set up so I can print out the arrays and I should be able to handle everything else. That being said, can anyone point me in the right direction?
You do not need a size variable and a top variable. They both measure the same thing on a stack because you always look at the top element. You only need one. If you use top you can simply return top + 1 from the size method. By the way, call it size() not getLength().
I suggest you go through the logic for push. Forget about pop and peek for the time being. Do one thing at a time and you can sort pop and peek later. Let's imagine that you already have 20 elements on the stack and you want to push one more element. Let's imagine that you have sufficient capacity. Write down the values of:-
If you have satisfied yourself that push() is working correctly, you can consider the peek method. Do the same for pop
Beware: you can write pop in such a manner as to create a memory leak. Your pop method will not compile because you have code after a return.
Campbell, I want to understand why you've said RuntimeException. Is this because the only way this exception can be encountered is through a flaw in the client code? Do we use RuntimeExceptions in such scenarios?
Campbell Ritchie wrote:Write one extending RuntimeException or one of its subclasses.
I am always slightly confused about which one to extend.
For example, if the API docs of the class specifies that "you should not call pop() if the stack is empty" then I would expect a RuntimeException to be thrown if a call is made to pop() when the stack is empty. If the programmer is testing his code properly, then he should see the exception getting thrown and he can make the appropriate code changes to check for isEmpty() before making the call to pop(). On the other hand, you could design your stack to be more forgiving and just return null when you try to pop() an empty stack. I'm sure there will be those who will argue for going one way or the other.
Campbell Ritchie wrote:I woiuld suggest that returning null is worse than throwing an unchecked exception. Remember that null might be a valid element on the stack.
Not all stacks are designed equally. The java.util.Stack has the semantics you mention but that's not the be-all and end-all of stack design and semantics. There are stack designs where pop() returns void and you have to use top() to get a reference to the top element. You could design a stack that doesn't accept null elements, so a pop() that returns null is not all that bad vs throwing an exception. It all depends.
In this case, however, given the OP's requirements, I agree that throwing an EmptyStackException would be the right thing to do.
I don't see a need for the stackESize variable. It's just one more thing to track and an additional potential source of bugs. I would just calculate it as getLength() -> top + 1.
W Wilson wrote:Right. Made some changes. Now, I just gotta figure out a way to print out all of the elements in a stack (preferred on the same line) and I should be good. Any ideas?
Yes. have a look at Arrays.toString(). You might have to copy the contents to an array of the right length first, but Arrays (java.util.Arrays) also has methods for doing that.
As Campbell says, your implementation is certainly along the right lines - and it's nice and simple (which is always a good place to start). but here's a couple of things to consider:
1. What if you push the n+1th element for a Stack of size n? The method will certainly throw an Exception, but what if someone calls that method from a try...catch block? In theory, they could simply log the error and then call the method again - and in that case, what would the value of top be?
The simple answer is: I'm not sure; but I suspect it means that top could exceed stackArray.length.
2. Same question with pop(): What if it's called several times in succession when the stack is empty? I suspect that means that top could end up being less than -1. And for that reason alone, it might be better to implement isEmpty() as:
return top < 0;
The exception is thrown in the push method's first line. Surely when the Exception is created, the program state is wound back to what it was before. So there will be no risk of top exceeding the size of the stack. Similarly for empty stacks top cannot be less than −1.
Winston Gutkowski wrote: . . .
1. What if you push the n+1th element for a Stack of size n? The method will certainly throw an Exception, but what if someone calls that method from a try...catch block? In theory, they could simply log the error and then call the method again - and in that case, what would the value of top be? . . .