Разница между Throws в сигнатуре метода и операторами Throw в Java

Вы во многом правы. За исключением одной вещи, о которой я упомяну чуть позже.

throws — такая же часть API метода, как имя и параметры. Клиенты знают, что если они вызывают этот метод, им нужно обработать это исключение — либо просто генерируя его, либо перехватывая и обрабатывая его (что на самом деле может повлечь за собой генерирование другого исключения, обертывающего оригинал). throws адресуется во время компиляции.

throw — это фактическое действие, позволяющее среде выполнения узнать, что произошло что-то плохое, т. е. что исключительная ситуация, о которой мы беспокоились, действительно имела место. Поэтому с этим нужно разбираться во время выполнения.

Но вы были не совсем правы, когда сказали: «Выбросы в сигнатуре метода всегда должны появляться, если в методе существует оператор throw». Часто это так, но не всегда. Я также мог бы вызвать другой метод, который генерирует исключение внутри моего метода, и если я его не перехватываю, мой метод должен его сгенерировать. В этом случае у меня нет явного броска того же исключения.

Наконец, вам нужно объявить исключение в throws только в том случае, если оно является проверенным исключением, то есть оно находится на другой стороне иерархии классов исключений от Исключение во время выполнения. Распространенными проверенными исключениями являются IOException и SQLException. Проверенные исключения должны быть перечислены в части throws сигнатуры метода, если вы не обрабатываете их самостоятельно. Все, что является подклассом RuntimeException, например NoSuchElementException в вашем примере, а также ненавистное исключение NullPointerException, является непроверенным исключением, и его не нужно ловить или бросать или что-то в этом роде.

Как правило, вы используете проверенные исключения для восстанавливаемых проблем (когда клиент знает, что может произойти, и может изящно справиться с проблемой и двигаться дальше) и непроверенные исключения для катастрофических проблем (например, не может подключиться к базе данных).

Если вы можете обойти все аспекты АОП, это отличное обсуждение как вы эффективно используете проверенные и непроверенные исключения.

Видья дал отличный ответ на ваши вопросы.

Самые важные слова: "И последнее, что вам нужно объявить исключение в бросках, только если это проверенное исключение"

Просто чтобы показать вам пример кода, что это значит. Представьте, что мы хотели бы использовать FileOutputStream для передачи некоторых данных. Функция будет выглядеть так:

public void saveSomeData() throws IOException {
  FileInputStream in = null;
  FileOutputStream out = null;

  try {
    in = new FileInputStream("input.txt");
    out = new FileOutputStream("output.txt");
    int c;

    while ((c = out.read() != -1) {
      in.write(c);
    }
  } catch (Exception e) {
    e.printStackTrace();
  } finally {
    // Close in
    if (in != null) {
      in.close(); // <-- If something bad happens here it will cause runtime error!
    }
    // Close out
    ...
  }
}

А теперь представьте, если бы вы не предоставили throws IOException и что-то плохое произошло внутри оператора finally{}, это вызвало бы ошибку.

Атрибут throw в сигнатуре метода, как вы правильно догадались, является подсказкой компилятору о том, что метод вызывает исключение, которое должно быть перехвачено вызывающей стороной. Исключение такого типа, называемое проверенное исключение, вызывающая сторона ДОЛЖНА всегда перехватывать или снова отправлять вызывающей стороне. Это что-то на уровне компилятора, сигнатура указывает, какое исключение метод может генерировать: это обеспечивает try-catch или повторную отправку в вызывающем объекте, а оператор throw где-то внутри метода — это ограничение, которое разработчик накладывает, чтобы указать что-то о поведение метода.

С другой стороны, другие исключения, а именно непроверенные или исключения времени выполнения (например, NoSucheElementException) — это исключения, которые вам не нужно указывать, поскольку они возникают в разных ситуациях.

Концептуальное отличие состоит в том, что проверяемые исключения обычно используются для предупреждения об исключительной ситуации, которая должна каким-то образом обрабатываться (подумайте о IOException) разработчиком, а непроверенные - это настоящие ошибки (например, NullPointerException или как в вашем примере NoSuchElementException)

RuntimeException не нужно обрабатывать в блоке try-catch, поэтому их не нужно объявлять брошенными и NoSuchElementException имеет значение RuntimeException, потому что оно расширяет его.