Java NoSuchElementException

user2651804 picture user2651804 · Sep 24, 2013 · Viewed 12.6k times · Source

So I have a pretty big java application that I wrote a year ago and I'm trying to understand it again. I'm looking at a method in the code where there is an obvious risk of getting NoSuchElementException: I'm calling .next() on a scanner variable that has been constructed with an arbitrary string. The only thing the method is declared to throw are custom made subclasses of Exception. The risky command isn't written in a catch-block either. The code compiles and works fine and when I use my gui in such a fashion that it should throw a NoSuchElementException nothing happens :O

As a test I wrote a catch-block into the code, compiled it, ran the gui and made it throw NoSuchElementException again and the application successfully caught the exception and acted accordingly. How is it that I can compile the code without specifying the this exception may be thrown? If it's any use at all, here is the code without the catch-block:

public static Expression interpret(final Scanner scanner)
  throws
    InvalidPosition,
    NoSuchSpreadsheet,
    IllegalStartOfExpression,
    InvalidExpression,
    FalseSyntax,
    InvalidRange {

String keyword = null;

try {
  keyword = scanner.next();
} catch (NoSuchElementException e) {
  throw new IllegalStartOfExpression();
}

switch(keyword) {
  case "Get":
    Position pos = PositionInterpreter.interpret(scanner.next());
    Expression expression = Application.instance.get(pos);
    if (expression instanceof Text) {
        System.out.println("Failure");
    } else { System.out.println("Success"); }
    return new Text(expression.toString());
  case "Int":
    return new Int(
      scanner.nextInt());

As you can see, the method simply assumes that there is more than one word in the scanner after checking if there is at least the one. How am I getting away with compiling this?

Answer

codeMan picture codeMan · Sep 24, 2013

It is be cause NoSuchElementException is unchecked exception, which means that it "is-a" RuntimeException which does not force you to catch.

The unchecked exceptions classes are the class RuntimeException and its subclasses, and the class Error and its subclasses. All other exception classes are checked exception classes. The Java API defines a number of exception classes, both checked and unchecked. Additional exception classes, both checked and unchecked, may be declared by programmers. See ref for a description of the exception class hierarchy and some of the exception classes defined by the Java API and Java virtual machine.

Runtime exceptions serve the same purpose as checked exceptions; to communicate exceptional conditions (unexpected failures, etc) to the user.

checked exception forces the caller of a method to handle that exception, even if they do not know how to handle it. Often times, developers will end up catching the checked exception, only to re-throw it (or another exception). Hence the Runtime exceptions

Here is the exception hierarchy

enter image description here