Why Java doesn’t have EmptyQueueException?











up vote
9
down vote

favorite
4












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?










share|improve this question




























    up vote
    9
    down vote

    favorite
    4












    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?










    share|improve this question


























      up vote
      9
      down vote

      favorite
      4









      up vote
      9
      down vote

      favorite
      4






      4





      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?










      share|improve this question















      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?







      java






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 50 mins ago

























      asked 1 hour ago









      Hai Hoang

      396313




      396313
























          4 Answers
          4






          active

          oldest

          votes

















          up vote
          2
          down vote



          accepted










          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 condition1.



          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 then2.



          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.






          share|improve this answer






























            up vote
            4
            down vote













            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.






            share|improve this answer





















            • Do you mean the poll method?
              – Hai Hoang
              1 hour ago








            • 3




              It is noteworthy though that many other collection and collection-esque classes use NoSuchElementException to indicate they're empty - everything from Enumeration to Stack's own superclass, Vector.
              – Vasan
              1 hour ago




















            up vote
            3
            down vote













            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()






            share|improve this answer






























              up vote
              2
              down vote













              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.






              share|improve this answer





















              • True, but Stack's parent, Vector, was there in 1.0 and uses NoSuchElementException. Same with Enumeration (and it's child). So multiple (admittedly non-collections-framework) classes were already using NoSuchElementException
                – Vasan
                1 hour ago













              Your Answer






              StackExchange.ifUsing("editor", function () {
              StackExchange.using("externalEditor", function () {
              StackExchange.using("snippets", function () {
              StackExchange.snippets.init();
              });
              });
              }, "code-snippets");

              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "1"
              };
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function() {
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled) {
              StackExchange.using("snippets", function() {
              createEditor();
              });
              }
              else {
              createEditor();
              }
              });

              function createEditor() {
              StackExchange.prepareEditor({
              heartbeatType: 'answer',
              convertImagesToLinks: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53551057%2fwhy-java-doesn-t-have-emptyqueueexception%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              4 Answers
              4






              active

              oldest

              votes








              4 Answers
              4






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes








              up vote
              2
              down vote



              accepted










              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 condition1.



              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 then2.



              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.






              share|improve this answer



























                up vote
                2
                down vote



                accepted










                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 condition1.



                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 then2.



                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.






                share|improve this answer

























                  up vote
                  2
                  down vote



                  accepted







                  up vote
                  2
                  down vote



                  accepted






                  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 condition1.



                  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 then2.



                  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.






                  share|improve this answer














                  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 condition1.



                  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 then2.



                  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.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited 45 mins ago

























                  answered 56 mins ago









                  Stephen C

                  509k69554908




                  509k69554908
























                      up vote
                      4
                      down vote













                      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.






                      share|improve this answer





















                      • Do you mean the poll method?
                        – Hai Hoang
                        1 hour ago








                      • 3




                        It is noteworthy though that many other collection and collection-esque classes use NoSuchElementException to indicate they're empty - everything from Enumeration to Stack's own superclass, Vector.
                        – Vasan
                        1 hour ago

















                      up vote
                      4
                      down vote













                      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.






                      share|improve this answer





















                      • Do you mean the poll method?
                        – Hai Hoang
                        1 hour ago








                      • 3




                        It is noteworthy though that many other collection and collection-esque classes use NoSuchElementException to indicate they're empty - everything from Enumeration to Stack's own superclass, Vector.
                        – Vasan
                        1 hour ago















                      up vote
                      4
                      down vote










                      up vote
                      4
                      down vote









                      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.






                      share|improve this answer












                      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.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered 1 hour ago









                      Makoto

                      79.4k15122165




                      79.4k15122165












                      • Do you mean the poll method?
                        – Hai Hoang
                        1 hour ago








                      • 3




                        It is noteworthy though that many other collection and collection-esque classes use NoSuchElementException to indicate they're empty - everything from Enumeration to Stack's own superclass, Vector.
                        – Vasan
                        1 hour ago




















                      • Do you mean the poll method?
                        – Hai Hoang
                        1 hour ago








                      • 3




                        It is noteworthy though that many other collection and collection-esque classes use NoSuchElementException to indicate they're empty - everything from Enumeration to Stack's own superclass, Vector.
                        – Vasan
                        1 hour ago


















                      Do you mean the poll method?
                      – Hai Hoang
                      1 hour ago






                      Do you mean the poll method?
                      – Hai Hoang
                      1 hour ago






                      3




                      3




                      It is noteworthy though that many other collection and collection-esque classes use NoSuchElementException to indicate they're empty - everything from Enumeration to Stack's own superclass, Vector.
                      – Vasan
                      1 hour ago






                      It is noteworthy though that many other collection and collection-esque classes use NoSuchElementException to indicate they're empty - everything from Enumeration to Stack's own superclass, Vector.
                      – Vasan
                      1 hour ago












                      up vote
                      3
                      down vote













                      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()






                      share|improve this answer



























                        up vote
                        3
                        down vote













                        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()






                        share|improve this answer

























                          up vote
                          3
                          down vote










                          up vote
                          3
                          down vote









                          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()






                          share|improve this answer














                          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()







                          share|improve this answer














                          share|improve this answer



                          share|improve this answer








                          edited 57 mins ago

























                          answered 1 hour ago









                          Mohamed Anees A

                          575413




                          575413






















                              up vote
                              2
                              down vote













                              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.






                              share|improve this answer





















                              • True, but Stack's parent, Vector, was there in 1.0 and uses NoSuchElementException. Same with Enumeration (and it's child). So multiple (admittedly non-collections-framework) classes were already using NoSuchElementException
                                – Vasan
                                1 hour ago

















                              up vote
                              2
                              down vote













                              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.






                              share|improve this answer





















                              • True, but Stack's parent, Vector, was there in 1.0 and uses NoSuchElementException. Same with Enumeration (and it's child). So multiple (admittedly non-collections-framework) classes were already using NoSuchElementException
                                – Vasan
                                1 hour ago















                              up vote
                              2
                              down vote










                              up vote
                              2
                              down vote









                              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.






                              share|improve this answer












                              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.







                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered 1 hour ago









                              Roland Illig

                              29k95790




                              29k95790












                              • True, but Stack's parent, Vector, was there in 1.0 and uses NoSuchElementException. Same with Enumeration (and it's child). So multiple (admittedly non-collections-framework) classes were already using NoSuchElementException
                                – Vasan
                                1 hour ago




















                              • True, but Stack's parent, Vector, was there in 1.0 and uses NoSuchElementException. Same with Enumeration (and it's child). So multiple (admittedly non-collections-framework) classes were already using NoSuchElementException
                                – Vasan
                                1 hour ago


















                              True, but Stack's parent, Vector, was there in 1.0 and uses NoSuchElementException. Same with Enumeration (and it's child). So multiple (admittedly non-collections-framework) classes were already using NoSuchElementException
                              – Vasan
                              1 hour ago






                              True, but Stack's parent, Vector, was there in 1.0 and uses NoSuchElementException. Same with Enumeration (and it's child). So multiple (admittedly non-collections-framework) classes were already using NoSuchElementException
                              – Vasan
                              1 hour ago




















                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Stack Overflow!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.





                              Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                              Please pay close attention to the following guidance:


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53551057%2fwhy-java-doesn-t-have-emptyqueueexception%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              數位音樂下載

                              When can things happen in Etherscan, such as the picture below?

                              格利澤436b