czy funkcje w javie nadal muszą mieć określone czy rzucają wyjątek?

O javie dawno temu czytałam więc nie jestem na bieżąco, a teraz muszę patrzeć w dość dawno napisane kody.
I widząc nagłówek jednej funkcji

 void JakasFunkcja(JakisParametr jp) throws Exception 

mam pytanie czy nadal trzeba tak pisać

Powiem szczerze, throws Exception to syf i przykro mi że z takim kodem musisz pracować :(
Ogólnie jeśli twoje wyjątki dziedziczą po RuntimeException to nie musisz ich wypisywać w sygnaturze metody. Są to wtedy wyjątki unchecked
Ogólnie consensus jest taki że używanie wyjątków nie dziedziczących po RuntimeException (czyli checked) jest złe.
Scala i Kotlin mają tylko wyjątki unchecked. W Javie można oszukać za pomocą adnotacji SneakyThrows, ale to jest naprawdę sneaky.
Ja osobiście nie lubię wyjątków i wolę metody/funkcje które zwracają Either/Option/Try

Jeśli to checked exception to trzeba pisać throws. Jeśli runtime to nie trzeba (ale weź pod uwagę że taki wyjątek jest niewidzialny i najpewiej wyleci na samą górę stosu i położy cały wątek). W praktyce zamiast checked exceptions może lepiej używać Try<T> albo Either<E,T>

Shalom napisał(a):

Jeśli to checked exception to trzeba pisać throws.

Chyba jednak będę musiał wyciągnąć książkę do javy i sprawdzić co to jest checked exeption ;)

@KamilAdam dobrze że tylko taki kod czytam, a nie muszę pisać ;)

widzę że tam wyjątki są użyte do zwracania wartości, w jednej funkcji rzucane, w drugiej łapane, dop[isywany jakiś tekst i rzucane znowu
ale to wszystko to nie jest jeszcze największe WTF jakie znalazłam w tym kawałku....

Chyba jednak będę musiał wyciągnąć książkę do javy i sprawdzić co to jest checked exeption

Byłem pewien że to precyzyjnie opisałem. checked to są te które nie dziedziczą po RuntimeException

KamilAdam napisał(a):

Scala i Kotlin mają tylko wyjątki unchecked. W Javie można oszukać za pomocą adnotacji SneakyThrows, ale to jest naprawdę sneaky.

Scala nie sprawdza typów rzucanych wyjątków, ale te typy zostają takie same. Jest to możliwe dlatego, że checked exceptions są sprawdzane przez kompilator Javy (polecenie javac), ale już olewane przez JVMa (polecenie java). SneakyThrows robi jakieś cuda z javową składnią, by obejść sprawdzenia w javac. Z dokumentacji Lomboka https://github.com/projectlombok/lombok/blob/6758714ed564d72236564889157c4812eacb96fb/src/core/lombok/Lombok.java#L37-L39 :

NB: The exception is not wrapped, ignored, swallowed, or redefined. The JVM actually does not know or care about the concept of a 'checked exception'. All this method does is hide the act of throwing a checked exception from the java compiler.