Object iloraz(double a, double b)
Oświecę cię, to zjeb*** rozwiązanie.
Dlaczego - odpowiedz mi? Czyżby zwracanie magic wartości nagle okazało się już faux pas? Bo ja wiem dlaczego jest to zjeb*** rozwiązanie, tak samo jak każde inne z podobnej serii. I nie ważne, czy wstawisz tam INF, 999.999, czy inne -1. Rozwiązanie jest IDENTYCZNIE zjeb***. No dobrze - twoje tutaj jest na dokładkę spieprzone, bo do odczytu poprawnej wartości musisz użyć rzutowania, które...ROTFL - nie zgadniesz co zrobi... ClassCastException. Szlag, exception w każdej szafie :D
Jedyny przypadek rzucania wyjątku przy operacjach matematycznych to dzielenie liczb całkowitych przez 0. Dlaczego ArithmeticException nie jest checked? Bo nikomu nie przychodzi na myśl, nawet największemu idiocie, żeby brać operację w try-catch
ROTFL. To już nagle nie wszystko zwraca NaN? Nagle jednak okazuje się, że nie zawsze dzielenie przez 0 daje prawidłowy wynik? Mistrzu - a mówiłeś, że to dozwolona operacja! I aby na pewno tylko to jedno? Wykonywałeś w javie kiedykolwiek jakiekolwiek bardziej złożone działanie od dodawania?
http://download.oracle.com/javase/1,5.0/docs/api/java/math/BigDecimal.html
żeby najśmieszniejszą funkcję przytoczyć:
/**
* ...
*@throws ArithmeticException if {@code divisor} is zero,
* ...
*/
public BigDecimal divide(BigDecimal divisor, int scale, int roundingMode)
Jest to literalnie nasza funkcja - funkcja podziel. O mój boże! Nikomu nie przyszło do głowy rzucać wyjątkami, tylko Sun wbrew twoim zaleceniom rzuca, no idioci! Pisz do nich petycję, żeby w JDK9 wydali specjalną edycję javy, i nową klasę BigDecimal retrofitted specjalnie z myślą o iooi, który ma swoje wizje.
http://commons.apache.org/math/api-2.2/index.html
Żeby komedię rozkręcić w pełni dodajmy, że w takim commons.math - pobieżnie licząc - siedzi ponad 40 różnych klas wyjątków - na pewno nikt nimi nie rzuca. Dla jaj zdefiniowali :D
Po prostu człowieku - do całego świata petycję chyba będziesz musiał pisać, bo apache.commons to jeden z najbardziej rozpowszechnionych projektów.
DANE SIĘ WALIDUJE, A NIE NA PAŁĘ WOŁA FUNKCJĘ, KTÓRA I TAK SIĘ wyrzuci.
Walidacja ma zawsze następować i po stronie konsumenta i po stronie producenta. Ponownie - nikt dla krotochwili nie umieścił w rdzeniu języka wyjątków IllegallArgumentException oraz IllegallStateException. Pisz do Sunowców odwołanie... cholera - Sunowcy poszli do Oracle, a Bloch do google'a zdaje się. O jej - zostałeś sam. Nikt Ci nie pomoże i nie naprawi twojej wizji świata wywalając z JDK takich paskudnych klas.
Math.sqrt zwraca NaN dla liczb ujemnych, nawet jeśli to nie jest to, czego oczekiwałeś (chociaż JEST TO WYNIK JAK NAJBARDZIEJ POPRAWNY).
Bo odziedziczył semantykę po C. Niemal całość funkcjonalności java.Math to kopia z "math.h". Jedna z rzeczy, z której m.in. Bloch nie jest specjalnie dumny. Niby bezpośrednie wsparcie dla IEEE. Ale połowiczne. Niby sygnalizacja błędów - ale połowiczna. No i przede wszystkim: NaN z definicji oznacza wynik niepoprawny, więc nie wykrzykuj głupot. Głupota wykrzyczana jest równie głupia, jak napisana kursywą. Przetłumacz sobie co te trzy literki oznaczają. Jak coś nie jest liczbą, to z całą pewnością nie może być z matematycznego punktu widzenia wynikiem działania zdefiniowanego na R
Jeśli mamy funkcję, która dyktuje kontrakt, a ktoś go w prosty sposób łamie, to go zwyczajnie za to karamy, ale nie każemy łapać jakichś debilnych wyjątków
Kara za złamanie kontraktu to właśnie wyjątek. Twoja "kara" nie jest zwyczajna, tylko psychopatyczna: randomizujesz działanie programu i powodujesz cichy błąd. Przyznaję - jest to okropna "kara". Każdego, kto zmusza mnie do uruchomienia debuggera i stawiania breakpointów i watch'ów w celu prześledzenia, co się właściwie dzieje w kodzie z całą pewnością również bym "ukarał". Inna sprawa - realizując w ciągu dwóch lat dwa projekty klasy krytycznej ze względu na niezawodność i bezpieczeństwo danych ani razu nie musiałem javowskiego kodu debugować. A błędów robię tyle co wszyscy - statystycznie co pół strony błąd. Sekret jest prosty: nie wymierzam sobie pojebanych kar w postaci pojebanych returnów, bo mi się jednego throw nie chciało umieścić.
A tego z infinity nie zrozumiałeś, nie zrozumiesz też dopóki nie pojmiesz tego, że jest to wynik poprawny (patrz wyżej), a nie sygnalizacją błedu.
To polecam przeczytać jednak ten standard IEEE. Owszem, dzielenie przez zero to jest nieprawidłowa operacja. Owszem - sqrt(-10) to jest nieprawidłowa operacja. Po prostu Java dziedzicząc konwencję po C zdecydowała (z perspektywy czasu - błędnie) nie stawiać trapów. Żeby było śmieszniej - cała nowa infrastruktura w Javie (patrz np commonsy) jak również sam standard IEEE zaleca obsługę tego za pomocą try-catch
http://en.wikipedia.org/wiki/IEEE_754-2008#Exception_handling
System.out.println("dupa, chociaż wszystko ok");
A nie żadne ify, ory i c**** wie co ty tam jeszcze sobie wymyślisz.
ROTFL, takiego komunikatu to się nie spodziewałem. "Dobrze, ale źle". Znaczy - źle, ale c**** wie dlaczego - więc operacyjnie załóżmy, że dobrze? Czy jak? :D Co to prostytutka za komunikat? "Operacja nie udała się i zakończyła się powodzeniem" ? ROTFL. To może od razu jawnie napisz:
System.out.println("nie mam pojęcia co o tym myśleć");
> Poza tym, wielki krucjatorku, albo niedokładnie czytasz, albo się trochę poddajesz. Wciąż nie odpowiedziałeś na to:
> iooi:I mówi to ktoś, kto pokazał kod, który nawet stacktrace wyjątku wypisał na stdout.
To teraz łaskawie zobacz gdzie ten stdout leży - w najszerszym catch'u, w funkcji main, tuż przed zakończeniem procesu. Jest to jedno z nielicznych miejsc, gdzie taka konstrukcja jest dozwolona - ponieważ już wiadomo, że wyleciałeś w powietrze, i nie możesz podjąć żadnej akcji ratowniczej. Nie jesteś wewnątrz żadnej funkcji obsługującej dziedzinę problemu. Nie możesz też odwoływać się do niczego poza stout oraz Logger - bo cały stan procesu może być niespójny, skoro do najbardziej zewnętrznego bloku aż wyjątek zaniosło.
I żeby było śmieszniej - ten println nie rzuca stacktrace, tylko czytelny opis błędu: "IlorazException: dzielenie przez zero nie lubieć ja". Właśnie dlatego out, a nie diagnostyczne err, bo jest to komunikat czytelny. Brawo - nawet nie wiesz jak działa funkcja, którą tak zalecasz.