Java exceptions that show the message when converted to String

Question

I’m working with custom exceptions in Java for stack operations. However, I’m unsure if the exception handling is being handled properly, especially in terms of how exceptions are thrown and caught. Can you review this code and explain how exception handling works here? Specifically, I need guidance on the use of checked vs. unchecked exceptions and whether the exceptions (StackOverFlow and StackUnderFlow) are being used correctly.

class StackOverFlow extends Exception
{
    public String toString()
    {
        return "Stack is Full";
    }
}

class StackUnderFlow extends Exception
{
    public String toString()
    {
        return "Stack is Empty";
    }
}

class Stack
{
    private int size;
    private int top=-1;
    private int S[];

    public Stack(int sz)
    {
        size=sz;
        S=new int[sz];
    }

    public void push(int x) throws StackOverFlow
    {
        if(top==size-1)
            throw new StackOverFlow();
        top++;
        S[top]=x;
    }

    public int pop() throws StackUnderFlow
    {
        int x=-1;

        if(top==-1)
            throw new StackUnderFlow();
        x=S[top];
        top--;
        return x;
    }
}

public class StackOverAndUnderFlow
{
    public static void main(String[] args)
    {
        Stack st=new Stack(5);
        try
        {
            st.push(10);
            st.push(15);
            st.push(10);
            st.push(15);
            st.push(10);
            st.push(15);

        }
        catch(StackOverFlow s)
        {
            System.out.println(s);
        }

    }
}

StackOverFlow: This exception is thrown when an attempt is made to push an item onto a full stack.

StackUnderFlow: This exception is thrown when an attempt is made to pop an item from an empty stack.

2. Stack Class

Fields:

• size: The maximum size of the stack.
• top: Tracks the index of the top element in the stack. It's initialized to -1, indicating an empty stack.
• S: An array to store the elements of the stack

Code is working fine but how do I deal such questions in interview?

Answer 1

Addressing the ugliness of an easy-to-get-wrong precept, not exception handling

Review

Adapt to working with array indexing that begins with 0 (because it does.)
An array to hold 3 elements uses elements arr[0], arr[1], and arr[2].
If the array represents a 'stack', the "stack pointer" (aka index) can point to the NEXT available position of the stack.

This means an empty stack uses an index of 0. Using post increment, after pushing one item onto the stack, the stack pointer/index now contains 1, which is simultaneously the updated next available position, AND the number of stored items.

Suggest you revise this code to work with post increment when pushing, and pre decrement when popping based on 0 meaning the stack is empty and idx == sz meaning the stack is full to capacity. It's much, much simpler than all the presented -1 adapting of values...

---

How useful would a stack be if mistakenly created with zero capacity? Should this be prevented at the time of creation?

Answer 2

Review

• The syntactic form int S[]; was added to Java to be compatible with C/C++. It is more logical to write int[] s; keeping type parts together. (Relevant in an interview.)

• When overriding methods, even for interfaces, use @Override. This ensures that typos are immediately recognized.

• Exception is the base class for checked exceptions, where you need to have a try-catch or for the moment a throws. For these kind of errors here, use a run-time exception. IllegalStateException and IllegalArgumentException are versatile base classes for a RuntimeException. You could also think of IndexOutOfBoundsException. Also mostly the naming ends with Exception or Error.

• Size I renamed to capacity to be more clear. As the .length field of an array gives that value, use that. (Relevant in an interview.)

• top or even sp are okay, but again count is more precise. Additionally it has the advantage of writing pop shorter.

• As the stack array values is created once for the life time of the Stack object, make it final, "constant".

• Style: except of S which should start with a small letter, it is okay. But an opening brace at the end of a line is still majority. Always braces is favoured too.

• Using toString for the eror message might be a correct way, but I do:

    public StackOverflow() {
        super("Stack is Full"); // Overriding the constructor with the nessage.
    }
  

Your issue with Exception

The checked Exception needing explicit code, requiring that the exception is handled, is what seems to be your problem, Here a checked exception is not needed.

When reading from files it would make sense, as easily a file could not exist or not being readable.

    try {
        Path directory = Paths.get(System.getProperty("user.home"));
        Files.list(directory).forEach(p -> System.out.println(p.getFileName()));
    } catch (IOException ex) {
        System.out.println("Could not list directory: " + e.getNessage());
    }
    

Corrected

class StackOverFlow extends IllegalStateException {

    @Override
    public String toString() {
        return "Stack is Full";
    }
}

class StackUnderFlow extends IllegalStateException {

    @Override
    public String toString() {
        return "Stack is Empty";
    }
}

class Stack {

    private final int[] values;
    private int count = 0;

    public Stack(int capacity) {
        values = new int[capacity];
    }
    
    public int getCapacity() {
        return values.length;
    }

    public void push(int x) throws StackOverFlow {
        if (count == values.length) {
            throw new StackOverFlow();
        }
        values[count] = x;
        ++count;
    }

    public int pop() throws StackUnderFlow {
        if (count == 0) {
            throw new StackUnderFlow();
        }
        --count;
        return values[count];
    }
}

count would not need to be initialized, automatically zero. One could initialize it in the constructor where the array is created.

Answer 3

In addition to the reviews already present, I want to assure you that you got the concept right, when to throw an exception (that's always a tricky question, and IMHO it's hard to find web resources that concentrate on that aspect - many just talk about the mechanics of exceptions, not their meaning).

An exception signals to the caller of a method that (for whatever reason) it failed to do its job.

In your case:

• The push() method has the job to add one element on the top of the stack, with the implicit assumption that the corresponding pop() will return that element. So, implemented with a limited-size array under the hood, the Stack can get full, unable to accept and later reproduce (in pop()) the new element.
• The pop() method's job is to return the element that was earlier added to the stack in the corresponding push() call. If you try to pop() more often than you pushed, there is no such element, and the method cannot return a correct result.
• You made sure in both methods that you leave the Stack instance in a consistent state, in your case being the same state as if the failing call hadn't happened at all. Perfect.

It's absolutely valid to throw exceptions in both situations, as you do.

Before the invention of exceptions, you had to extend the parameters or return values of your methods with some way of signalling failure (e.g. returning -1 from pop() in such a case), but that had lots of pitfalls.

There's only one thing I'd do differently, but that's a bit of personal taste:

I'd simply use pre-existing exception types:

• I'd have push() throw an IllegalStateException (as does the add() method of Queue).
• I'd have the pop() method use NoSuchElementException.

Why?

The question is: "What's the benefit for the caller that justifies the introduction of specific exception types?"

Typically, your caller needs to know that some call failed, and not so much why it failed. From that point of view, any exception type will do.

The "why" (represented in the exception instance) is important for later analysis by an administrator or a developer in a debugging session, so it's a good thing to log it, together with the stack trace, into some log file or a similar storage. So, make sure, the exception contains the analysis-relevant information in the toString() representation of the exception.

In the stack-overflow case, it might be useful to mention the stack size in the exception message, as seeing a zero-size stack overflow leads to a completely different error analysis (wrong Stack initialization) when compared with overflowing a size-1000000 stack (probably a logic error like an endless loop).