Nsryjdtyk

In the pop method of java.util.Stack class, it throws EmptyStackException if the Stack is empty. But the remove method (which similar to pop in Stack class) of java.util.Queue instead throws NoSuchElementException. why there is this inconsistency in the JDK implementation?

The Stack class is a legacy class from the Java 1.0 days, prior to the introduction of the collections framework. It's interface has to be backwards compatible ... and that is how it was designed.

By contrast, the Queue interface was introduced in the Java 1.5 revision of the collections framework. By that time, the NoSuchElementException had been chosen by the designers as the best way to express this kind of error condition¹.

Note that NoSuchElementException could have been used in Stack since both classes existed in Java 1.0, but clearly, the designers had other ideas back then².

So this is just a historical anomaly that has arisen due to the way that the Java APIs have evolved. It cannot be fixed without breaking binary compatibility for existing applications that use the Stack class.

^{1 - You may disagree with that, but you asked why, and this is why.}

^{2 - Or maybe they were just too rushed to get the API design correct. The Java 1.0 release was made under extreme pressure to meet a perceived market opportunity. A few mistakes were made and could not be corrected in time. Other examples include the Enumeration API, the deprecated Thread methods, the Hashtable and Vector classes, StringBuffer and so on. But once Java 1.1 was released, it was too late.}

Queues have special methods which allow it to return null instead of throw an exception. This is useful in the case of a BlockingQueue, which should block until a value appears, or throw an exception.

The legacy class in this case - Stack - is special in that it throws its own exception when it's empty. There's no real inconsistency here in that the exceptions are different, it's just that the collections are serving two completely different purposes. If nothing else, this is explicitly documented by the fact that the exceptions are different.

I guess there is no inconsistency or whatsoever confusion you have regarding this. Both the methods pop() and remove() are self-explanatory and extend RuntimeException. The exceptions are named as per proper conventions and stand themselves for explanation.

Queue-> remove() throws NoSuchElementException. As per docs, remove() Retrieves and removes the head of this queue. So, if the function performs only retrieval, it can return null and not throw Exception(Refer, poll()). In addition to retrieval, it also tries to remove the head of queue and hence NoSuchElementException is thrown.

Stack -> pop() throws EmptyStackException which means the stack is empty(It can also throw NoSuchElementException logically, but EmptyStackException is more clean and easy to debug the cause. Also, this Exception is thrown only by Stack class)

Coming to your exact answer, Stack is a class whereas Queue is an interface.
You can construct your own objects of Stack class, which means it can have Exceptions precisely for it.

But Queue, being an interface, relies on (LinkedList,for example) for actual method declarations. Hence, if you plan to implement Queue<E> by your own, you can have a EmptyQueueException or anything you like. But if you rely on LinkedList, it is simply not logical to expect an EmptyQueueException from LinkedList.remove()

The Stack class was there first. In the Javadoc it says "since JDK 1". It defined its own exception type because … it could.

At that same time, the NoSuchElementException already existed, but the Java collections framework didn't exist yet. Therefore it was not yet common to use that exception widely. It was "just one of the predefined exception" types.

The collections framework was added in Java 1.2, and it could not use the StackEmptyException because its name restricts it to be used only with stacks.

At that point, the old Stack class could not be modified anymore since that would have broken existing code. Java has been successful of being backwards compatible over decades, and the exception inconsistency is one sign of this compatibility.