Z czego wynikają różnice w obsłudze wyjątków z deklaracją 'throws' i bez?

Hej.

Czemu i z czego wynika różnica między obsługą wyjątków kiedy deklarujemy:

1. że dana metoda rzuca wyjątek (throws) i pod jakimś warunkiem rzucamy nowy (throw new ... ), i wtedy musimy albo obsłużyć blokiem try/catch albo przekazać dalej i zadeklarować rzucenie wyjątku w metodzie wywołującej.
   np.

  public Range(long lowerBound, long upperBound) throws Exception    {
        if (upperBound <= lowerBound) {
            throw new IllegalArgumentException("lowerbound is bigger than upperbound");
        }
        this.lowerBound = lowerBound;
        this.upperBound = upperBound;
    }

tutaj przy teście trzeba przynajmniej zadeklarować throws:

 public void shouldSayThat15IsInRange() throws Exception  {//....}

2)a przypadkiem, że metoda rzuca w ciele wyjątek (throw new.... ) bez deklaracji (throws) i wtedy nie musimy robić nic...

  public Range(long lowerBound, long upperBound)    {
        if (upperBound <= lowerBound) {
            throw new IllegalArgumentException("lowerbound is bigger than upperbound");
        }
        this.lowerBound = lowerBound;
        this.upperBound = upperBound;
    }

Tu przy np. Teście nie trzeba nic deklarować.

 public void shouldSayThat15IsInRange()  {//....}

Wyjątki, które dziedziczą z RuntimeException ( i Error) nie muszą byc deklarowane (zarówno twoje własne, które podzedziczysz z RuntimeException jak i standardowe IllegalArgumentException). To sa tzw. wyjatki unchecked. W odróżnieniu od innych, które są checked, i które trzeba deklarować lub łapać.

Druga sprawa to taka, że na dzień dzisiejszy tworzenie innego wyjątków czyli **checked **uznałbym za smród. Ciekawa koncepcja, ale nie sprawdziła się.

Bo jedne to wyjątki "checked" dziedziczące po Exception a drugie to wyjątki unchecked dziedziczące po RuntimeException. Te drugie zwykle sugerują ze coś poszło bardzo nie tak i zwykle jest sens je "łapać" bardzo wysoko, stąd też bez sensu byłoby deklarowanie rzucania ich przez wszystkie poziomy.
Jednocześnie wyjątki checked w rzeczywistości obsługuje się "blisko" i w większości sytuacji w ogóle nie bardzo jest sens je rzucać bo można sobie to od razu obsłużyć/sprawdzić i ewentualnie ogarnąć przez Optional czy Either.

Mój błąd wydawało mi się, że nie dziedziczy po RuntimeException i główkowałem haha :D Dziękuję !