2014.02.16 17:44
czym różni się RuntimeException od innych klas dziedziczących po Exception
Brian Goetz w "Java concurrency in practice" pisze: "The leading cause of premature thread death is RuntimeException. Because these exceptions indicate a programming error or other unrecoverable problem, they are generally not caught". A ja się z tym nie zgadzam. I zawsze twierdzę, że jedyna zasada, jaka rządzi tym, czy dany wyjątek jego twórcy uczynili dziedziczącym po RuntimeException czy też nie (czyli tylko po Exception) jest taka, że twórcy biblioteki mieli fanaberię, żeby programistę korzystającego z biblioteki zmuszać do obsługiwania tego wyjątku albo nie. Żadnej więcej reguły nie ma, żadnej więcej reguły nie stosują nawet sami twórcy Javy. Dowodzi tego to, że Integer.parseInt jak dostanie napis nie reprezentujący porządnie liczby rzuca NumberFormatException - który dziedziczy po RuntimeException - a NumberFormat#parse rzuca ParseException - dziedziczące po Exception bez pośrednictwa RuntimeException. A przecież sens problemu w obu przypadkach jest identyczny.
komentarze:
2014.02.16 20:50 jfedor
W Thinking in Java autor trochę analogizował między tym a typowaniem statycznym i dynamicznym (aczkolwiek z odwrotną konkluzją, przynajmniej tak mi się wydaje, że konsensus jest, że im większy projekt, tym bardziej się opłaca statyczne typowanie, a on uważał, że im większy projekt, tym mniej się opłacają sprawdzane (nie-Runtime) wyjątki).
2014.02.17 04:34 Piotrek
A czy jakoś to uzasadniał? Jeśli tak, to czy może pamiętasz, w którym to było rozdziale? To sobie poczytam.
2014.02.17 14:28 jfedor
W tej okolicy:
http://www.linuxtopia.org/online_books/programming_books/thinking_in_java/TIJ311_020.htm
Nie wiem jak inne wydania, ale to konkretnie chyba przyłapało autora w połowie kryzysu wiary w typowanie statyczne.
powrót na stronę główną
RSS