Prosta metoda dzielenia dwóch liczb

1
public static void main(String[] args){
		System.out.println("Iloraz: " + iloraz(4, 0)); 
		}  
	public static double iloraz(double a, double b){
		if (b!=0){
			return a/b;
		}
		else{
			System.out.println("Dzielnikiem jest zero ");
			return a/b;
		}
	}

Witam, mam mały problem, chcę zrobić metodę iloraz, która w razie gdy ktoś będzie dzielił przez 0 wyświetli stosowny komunikat. Niestety moja metoda musi zwracać wartości double, i w przypadku podanego kodu zwróci "Dzielnikiem jest zero, Iloraz: Infinity".
Czy jest jakaś możliwość zwrócenia informacji że nie wolno dzielić przez zero w obrębie tej metody, czy jest na to jakiś inny sposób?

0

Wyjątek.

0

Funkcja

        public static double iloraz(double a, double b)
        {
              return a/b;
        }

jest w Javie poprawna i zwraca zawsze wynik typu double. Możesz ją ewentualnie uzupełnić o wyświetlenie informacji, że wykonywana jest matematycznie niepoprawna operacja dzielenia przez zero.

1

Możesz też sprawdzać wynik dzielenia (Double.isInfinite(wynik)) i jeśli jest niepoprawny, zamiast niego wypisywać jakąś informację.

0
System.out.println("Iloraz: " + iloraz(4, 0)); 
        }  
public static double iloraz(double a, double b){
        if (b!=0){
                return a/b;
        }
        else{
                System.out.println("Dzielnikiem jest zero ");
                return -99999999.9;
        }
}
		
	}

Ja bym to tak rozwiązał.
Ewentualnie:

double a=4,b=0;

if (b!=0){
            System.out.println("Iloraz: " + iloraz(a, b)); 
          }  
public static double iloraz(double a, double b)
{
       
    return a/b;
       
}
		
	
3

Jezusie jedyny... chłop po ludzku pyta: "Czy jest jakaś możliwość ZWRÓCENIA informacji że nie wolno dzielić" - a wy nawalacie po System.out i debatujecie nad tym, jak WYKRYĆ to dzielenie...

@Marcin-ZG: za takie rzeczy w pracy morduję. Jak ktoś zwraca mi z jakiejś funkcji jakąś "magiczną wartość" która należy do dziedziny poprawnych wyników to lecą kur***, c****, a na koniec idę zapalić. Jak już tak robisz, to przynajmniej napisz, jak to się po ludzku robi! To znaczy: zwracając magic-number obowiązkowo javadoc'ujesz funkcję.

Przekazywanie takich błędów możesz zrealizować na 3 sposoby, od najlepszego, do najgorszego (wg mojego uznania). Opcja pierwsza: Robisz własny wyjątek, checked wyjątek - każdy musi się z nim liczyć i przechwytywać. Nie sposób nie zauważyć, że funkcja może wyrzucić błędem - nawet od razu w deklaracji widać mniej więcej jakiego rodzaju, a kompilator zmusi to try-catch. Sposób bezpieczny, sposób z drugiej strony: upierdliwy.

public static final class IlorazException extends Exception {

    public IlorazException(String message) {
        super(message);
    }

    public IlorazException(Throwable cause) {
        super(cause);
    }

}

public static double iloraz(double a, double b) throws IlorazException {
    if (b != 0) {
        return a / b;
    } else {
        throw new IlorazException("dzielenie przez zero nie lubieć ja");
    }
}


public static void main(String[] args) {
    try {
        System.out.println("Iloraz: " + iloraz(4, 0)); // wywołujesz w try-catch
    } catch(IlorazException cause) {
        System.out.println( cause ); // reagujesz na błąd, jeśli jakiś się pojawi
    }
}

No dobra, no to mniej upierdliwa wersja z wyjątkiem. Wyjątek typu unchecked. Niczego nie musisz deklarować, a ludź wywołujący nie musi przechwytywać. Oczywiście w dobrym tonie by było, jakby jednak przechwytywał, w try-catch'u wywołując. Ale może komuś się nie chce pisać non-stop try-catchów. Wygodniejsze więc, ale mniej bezpieczne: nieprzechwycony wyjątek wysadzi Ci w powietrze program. No dobra - Bogu dzięki, że własny wyjątek zrobiłeś, z sensownym komunikatem... więc mimo braku obsługi błędu jako tako to wygląda.

public static final class IlorazException extends RuntimeException {

    public IlorazException(String message) {
        super(message);
    }

    public IlorazException(Throwable cause) {
        super(cause);
    }
}
    
public static double iloraz(double a, double b) {
    if (b != 0) {
        return a / b;
    } else {
        throw new IlorazException("dzielenie przez zero nie lubieć ja");
    }
}

public static void main(String[] args) {
    System.out.println("Iloraz: " + iloraz(4, 0));
}

Opcja trzecia, jeśli ktoś naaaprawdę nienawidzi wyjątków, i MUSI z sobie tylko znanych przyczyn sygnalizować błąd za pomocą return... to niech wyp@!@!@! z jakimiś magicznymi liczbami, tylko zwraca coś, co od razu można rozpoznać jako wynik z d**y wzięty. Co na pewno jest wynikiem idiotycznym? Natychmiast każdy zauważy? null. Tylko, że null to z obiektami można używać, a nie z typami prostymi... no to funkcja do przeróbki musi pójść odrobinę - trzeba double zamienić na Double.

/**
 * Dzieli liczby
 * @param a dzielna
 * @param b dzielnik
 * @return iloraz albo {@code null} jeśli operacja niedozwolona
 */
public static Double iloraz(double a, double b) {
    if (b != 0) {
        return a / b;
    } else {
        return null;
    }
}

public static void main(String[] args) {
    Double result = iloraz(4, 0);
    if(result != null) {
        System.out.println("Iloraz: " + iloraz(4, 0));
    } else {
        System.out.println("ojejku");
    }
}

Ta trzecia opcja to najgorsza opcja, w 99% przypadków będziesz zapominał porównać z nullem i poleci NullPointerException - najpopularniejszy błąd w źle napisanych programach. Nawet nie myśl o pisaniu takich funkcji bez javadoc. Możesz olewać javadoc z góry na dół, możesz dawać idiotyczne nazwy funkcji, wszystko możesz pomijać, bo "nie ma czasu"/"nie chce mi się"/"zrobię jutro" - ale takie funkcje opisuj natychmiast. Opcja najgorsza, ale czasem ta opcja ma chyba sens, tak przypuszczam przynajmniej. Np ja tej opcji używałem w grupie kilkunastu funkcji, które miały coś sprawdzić, i zwrócić true/false. Dość szybko się okazywało, że funkcje muszą zwracać trzy wartości:

  • tak tak, włączono
  • nie włączono tego o co pytasz
  • eeee, ni c**** pojęcia nie mam, znaczy: nieokreślone

I szczerze mówiąc do takiej logiki trójwartościowej wolałem właśnie używać Boolean i zwracać true/false/null zamiast true/false/rzucenie wyjątku. Uznałem, że definiowanie własnego enuma akurat tutaj też jeszcze mi nie jest potrzebne, bo język całkiem nieźle i intuicyjnie trójwartościowość realizuje.

4

*Bo tylko ty uznałeś, że rzucanie w tym kodzie wyjątkami ma jakiś sens. - iooi 56 minut temu *

tak debilu - bo nie można sygnalizować błędu za pomocą zwracania wyniku jeśli KAŻDA wartość przyjmowana przez zmienną zwracaną może być wynikiem poprawnej operacji.

tak debilu - bo błędy obsługujesz throwami i catchami, a kontrolę przepływu if'ami i returnami. Nie na odwrót.

Jak masz ochotę się z c**** na głowy zamieniać albo nogami pisać - twój problem. Ale wyraźnie i za każdym razem będę powtarzał: zły kod to zły kod, a sranie pod siebie to sranie pod siebie.

Można też sprawę ująć inaczej: uznałem tak właśnie, bo o to facet pyta właśnie: jak sygnalizować prostytutka błąd. A nie jak odróżniać czy złe dzielenie zaszło, bo to żadna filozofia przed dzieleniem porównanie z zerem porównać. Co zresztą facet zrobił w poście otwierającym pytanie.

Błędów się nie sygnalizuje napierdalając po konsoli, bo 99% twoich programów, szczególnie w Javie, konsolowa nie będzie. Zresztą takie "sygnalizowanie" to w dupę sobie można wsadzić bo konsola znika razem z procesem - od tego masz javowskie Logger, albo inne log4j, jeśli już coś trace'ować chcesz.

0

Tak debilu, ale dzielenie przez zero dla doubli jest well-defined. Nigdzie nie pisałem nic o konsoli, debilu.
To żadna filozofia zasygnalizować błąd, bo to żadna filozofia rzucić wyjątkiem (to przecież oczywiste).

3

Przepiszę jeszcze raz pierwsze pytanie z wątku: Czy jest jakaś możliwość zwrócenia informacji że nie wolno dzielić przez zero.
Nie wykrycia, nie sprawdzenia - bo to już gość zrobił. Tylko ZWRÓCENIA INFORMACJI. Z naciskiem na informację.

iooi napisał(a)

Nigdzie nie pisałem nic o konsoli

iooi napisał(a)

i jeśli jest niepoprawny, zamiast niego wypisywać jakąś informację.

Albo nie wiesz co piszesz, albo masz słabą pamięć, albo kłamiesz. A koniec końców meritum jest takie, że ta rada jest ZŁA.

Po wykryciu nieprawidłowego zdarzenia w programie podejmujesz ZAWSZE inne działania niż wypisywanie. Uogólniając: albo naprawiasz nieprawidłowy stan, albo - jeśli nie wiesz jak to zrobić - a funkcja dzieląca z pewnością nie ma o tym pojęcia - propagujesz informację (jezu, chłopak już zadając pytanie sam zdefiniował kluczową cześć odpowiedzi!) o błędzie wewnątrz PROGRAMU, w górę, aż w końcu dotrze to do takiego miejsca, które już będzie wiedziało, co z tym fantem zrobić.

Szczególnie wszelkiego rodzaju błędy "logiki biznesowej" muszą być propagowane za pomocą mechanizmu, który niesie znaczenie dla maszyny, dla programu, dla kodu. Bo to kod działa i to kod jest analizowany. "return coś" niesie programowi prostą informację: funkcja wykonała return, znaczy zakończyła się poprawnie, znaczy wszystko jest cudownie. Żaden debugger, narzędzie profilujące, narzędzia kontroli jakości kodu nic z tej konstrukcji nie wyłapią. Stwierdzą, że jest super...

A super nie jest, bo dzielenie przez zero jest well-defined z technicznego punktu widzenia. A ta funkcja nie ma rozwiązywać problemu tranzystorów, tylko problem matematyczny. Czyli zewnętrzna komunikacja: typy argumentów, typy wyników i dozwolone operacje masz czerpać z dziedziny problemu a nie z dziedziny implementacji. Co mnie obchodzi, że standard IEEE pozwala na takie akcje? Co mnie obchodzi, że funkcja w ogóle wewnętrznie posługuje się jakimś standardem IEEE do reprezentacji liczb? Mnie obchodzi, że każdy matematyk zawału dostanie na widok 10/0 = INFINITY. My na liczbach do jasnej anielki pracujemy? Czy też może właśnie napisaliśmy super-duper hybrydową funkcję, która niby pracuje na liczbach, ale czasem to zachowuje się tak, jakby sobie traktowała to jako ciągi nieskończone i używając w dodatku niezłego skrótu myślowego zwracała wynik, który również jest niezłym skrótem myślowym.

O mój przyjacielu - słowo "pUpcia" do bazy danych też mogę wpisać, kodowanie UTF8 mi na to pozwoli. Ale jaknapiszę tezaurus nawalający takimi kwiatkami, to każdy normalny użytkownik stwierdzi, że program daje zwyczajnie błędne wyniki, żeby nie powiedzieć karygodne, bo wprowadzające w błąd (zupełnie jak twoja funkcja zwracająca infinity!). I nikogo nie będzie interesować, że SQL-owe INSERT jest well-defined dla ciągów "pUpcia".

Wypisanie, a raczej LOGOWANIE informacji do DZIENNIKA to tylko działanie dodatkowe. Wyświetlanie komunikatu użytkownikowi programu zaś to zdecydowanie zadanie dla zupełnie innej części programu niż funkcja matematyczna, która nie ma pojęcia w jakim kontekście została wywołana i w jaki sposób prowadzony jest dialog z userem. I czy w ogóle jakiś dialog jest prowadzony.

1
Ranides napisał(a)
iooi napisał(a)

Nigdzie nie pisałem nic o konsoli

iooi napisał(a)

i jeśli jest niepoprawny, zamiast niego wypisywać jakąś informację.

Albo nie wiesz co piszesz, albo masz słabą pamięć, albo kłamiesz. A koniec końców meritum jest takie, że ta rada jest ZŁA.
Nadal jestem pewien, że nie pisałem tu nic o konsoli. Wypisywać można logując, jeśli tak bardzo to kochasz.

Ranides napisał(a)

Po wykryciu nieprawidłowego zdarzenia w programie podejmujesz ZAWSZE inne działania niż wypisywanie. Uogólniając: albo naprawiasz nieprawidłowy stan, albo - jeśli nie wiesz jak to zrobić - a funkcja dzieląca z pewnością nie ma o tym pojęcia - propagujesz informację (jezu, chłopak już zadając pytanie sam zdefiniował kluczową cześć odpowiedzi!) o błędzie wewnątrz PROGRAMU, w górę, aż w końcu dotrze to do takiego miejsca, które już będzie wiedziało, co z tym fantem zrobić.
Szczególnie wszelkiego rodzaju błędy "logiki biznesowej" muszą być propagowane za pomocą mechanizmu, który niesie znaczenie dla maszyny, dla programu, dla kodu.
Pierdzielisz o logice biznesowej i logowaniu, a przecież od razu widać, że autor pisze program konsolowy. Mi np. grep nigdy żadnym wyjątkiem nie wypierdolił.

Ranides napisał(a)

Mnie obchodzi, że każdy matematyk zawału dostanie na widok 10/0 = INFINITY. My na liczbach do jasnej anielki pracujemy? Czy też może właśnie napisaliśmy super-duper hybrydową funkcję, która niby pracuje na liczbach, ale czasem to zachowuje się tak, jakby sobie traktowała to jako ciągi nieskończone i używając w dodatku niezłego skrótu myślowego zwracała wynik, który również jest niezłym skrótem myślowym.
(...)
Wypisanie, a raczej LOGOWANIE informacji do DZIENNIKA to tylko działanie dodatkowe. Wyświetlanie komunikatu użytkownikowi programu zaś to zdecydowanie zadanie dla zupełnie innej części programu niż funkcja matematyczna, która nie ma pojęcia w jakim kontekście została wywołana i w jaki sposób prowadzony jest dialog z userem. I czy w ogóle jakiś dialog jest prowadzony.
Funkcje matematyczne nie rzucają wyjątków. Po prostu albo są, albo nie są określone na danej dziedzinie.
A dzielenie doubli w Javie jest określone na każdym doublu i zawsze jest poprawne. To wynik może być niepoprawny.

Podsumowując - napisałbyś odpowiedni kod tak (częściowo abstrahując od pytania autora):

public static final class WtfException extends Exception {
    public WtfException(String message) {
        super(message);
    }
 
    public WtfException(Throwable cause) {
        super(cause);
    }
}
 
public static Bar doSth(Foo foo) throws WtfException {
    if (foo...) {
        return...;
    } else {
        throw new WtfException("dupa");
    }
}
 
 
public static void main(String[] args) {
    try {
        System.out.println(doSth(...)); // wywołujesz w try-catch
    } catch(WtfException cause) {
        System.out.println(cause); // reagujesz na błąd, jeśli jakiś się pojawi
    }
}

Czy tak:

public static void main(String[] args) {
    if (foo...) {
        System.out.println(...);
    } else {
        System.out.println("dupa"); // reagujesz na złe dane, jeśli są złe
    }
}

?
Twoje rozwiązanie jest równie złe co nasze.

2

Nadal jestem pewien, że nie pisałem tu nic o konsoli. Wypisywać można logując, jeśli tak bardzo to kochasz.

Nadal więc podtrzymuję tezę o debilu, zwłaszcza, że nawet debila starasz się udawać. Pocieszę Cię, nie musisz udawać. Oczywistym jest, że polecenie: "wypisz" nie dotyczyło pisania do otwartego połączenia z serwerem tylko oznaczało nawalanie na ekran.

Pierdzielisz o logice biznesowej i logowaniu, a przecież od razu widać, że autor pisze program konsolowy. Mi np. grep nigdy żadnym wyjątkiem nie wypierdolił.

To zapraszam łaskawie kiedykolwiek rzucić okiem na JAKIKOLWIEK program konsolowy, który nie jest pisany przez domorosłego łosia, tylko ma zastosowanie w kodzie produkcyjnym. Np na mavena. Tak - rzuca wyjątkami. I tak: grep też rzuca "wyjatkami". Jak nastapi błąd, to nie klepie komunikatu na EKRAN (czyli na stdout) tylko czytelny kod leci na STDERR, a kod zakończenia programu jest RÓŻNY OD ZERO. Bo nie zgadniesz - do wymiany informacji o błędach między procesem a systemem operacyjnym nie służy nawalanie po ekraniku, ani nawet pisanie na stderr, tylko zwracanie ERRORCODE. Co grep oczywiście ROBI! A przede wszystkim: jak nauczyć się srać pod siebie pisząc "małe konsolowe programiki" to tak samo będziesz srał pod siebie pisząc coś realnego. Bo pisanie kodu to nawyki - albo zawsze robisz dobrze, albo odstawiasz chałturę.

Twoje rozwiązanie jest równie złe co nasze.

Albo nie umiesz czytać, albo myśleć - albo po prostu nie rozumiesz co to jest wyjątek. Być może dlatego, że nie piszesz nic sensownego. Trudno powiedzieć. Sygnalizowanie błedów poprzez return value to lata 70-te XX wieku. Mamy trochę bardziej rozwinięte języki wysokiego poziomu, i albo pisząc w HLLu używasz konwencji wysoko-poziomowych. Albo zasuwasz do asemblera i C. Sorry - nawet C ma mechanizm sygnałów i można w nim wysoko-poziomowo oznajmiać błędy.

Twoje rozwiązanie jest do d**y, bo kontrolę błędów realizujesz za pomocą konstrukcji, które służą do kontroli przepływu. Żeby w funkcji dzielącej nie przeoczyć tego twojego magicznego return MAGIC trzeba albo przeczytać body twojej funkcji albo javadoc'a (którego pewnie nie napiszesz - czyli zostaje body funkcji - cudownie - kilka(naście) minut analizy cudzego kodu, żeby załapać, co "może się stać po wywołaniu tego potworka"). Łatwo przeoczyć, łatwo zapomnieć - NIKT, ŻADNE narzędzie nie wskaże Ci tego jako potencjalny błąd.

Tymczasem o obsłudze checked wyjątków nie da się zapomnieć. A unchecked wyjątki może i mogą zostać zapomniane, ale nie spowodują żadnego undefined behaviour. Nieprzechwycone pójdą do catch'a wyżej. W twoim przypadku tymczasem pominięcie tego ifa i kontynuacja obliczeń na "magicznej wartości" da "magiczny wynik" bóg jeden wie jaki. I cholera wie kiedy i kto wykryje błąd.

Funkcje matematyczne nie rzucają wyjątków. Po prostu albo są, albo nie są określone na danej dziedzinie.

Jasne, i pewnie dlatego w rdzeniu języka (java.lang) masz całą serię wyjątków IllegalArgumentException / ArithmeticException / NumberFormatException / itd itp

A jak już chcesz sygnalizować przez coś returnowanego, to czymś, co jest jawnie błędne. Nie INFINITY, nie 999.999, tylko czymś, co spowoduje głośny, a nie "cichy błąd" Albo null'em, na którym próba policzenia czegokolwiek wywali NPE, albo chociażby NaN'em na Boga - bo na NaN większość funkcji też ma uczulenie i pójdzie głośny błąd.

0
Ranides napisał(a)

A jak już chcesz sygnalizować przez coś returnowanego, to czymś, co jest jawnie błędne. Nie INFINITY, nie 999.999, tylko czymś, co spowoduje głośny, a nie "cichy błąd" Albo null'em, na którym próba policzenia czegokolwiek wywali NPE, albo chociażby NaN'em na Boga - bo na NaN większość funkcji też ma uczulenie i pójdzie głośny błąd.
Nie wiem, czego nie rozumiesz w zdaniu o poprawności dzielenia przez 0 dla doubli. I że infinity to nie jest wartość niepoprawna ani sygnalizująca błąd.
Reszta tl;dr. Ale się postaram.

//OK:

Ranides napisał(a)

Nadal więc podtrzymuję tezę o debilu, zwłaszcza, że nawet debila starasz się udawać. Pocieszę Cię, nie musisz udawać. Oczywistym jest, że polecenie: "wypisz" nie dotyczyło pisania do otwartego połączenia z serwerem tylko oznaczało nawalanie na ekran.
O serwerze też nic nie pisałem. Uhm?

Ranides napisał(a)

Jak nastapi błąd, to nie klepie komunikatu na EKRAN (czyli na stdout) tylko czytelny kod leci na STDERR, a kod zakończenia programu jest RÓŻNY OD ZERO. Bo nie zgadniesz - do wymiany informacji o błędach między procesem a systemem operacyjnym nie służy nawalanie po ekraniku, ani nawet pisanie na stderr, tylko zwracanie ERRORCODE.
I mówi to ktoś, kto pokazał kod, który nawet stacktrace wyjątku wypisał na stdout.

Ranides napisał(a)

Twoje rozwiązanie jest do d**y, bo kontrolę błędów realizujesz za pomocą konstrukcji, które służą do kontroli przepływu.
To twoje rozwiązanie jest do d**y, bo do kontroli przepływu używasz wyjątków.

Ranides napisał(a)

Jasne, i pewnie dlatego w rdzeniu języka (java.lang) masz całą serię wyjątków IllegalArgumentException / ArithmeticException / NumberFormatException / itd itp
Co to ma do funkcji matematycznych?

A rozwiązanie z nullem jest **ujowe, już lepsze infinity. Bo co ma null do dzielenia?

0

Widzę ostre rzucanie ku*wami i wyjątkami :D

Spokojnie....

2

A rozwiązanie z nullem jest **ujowe, już lepsze infinity. Bo co ma null do dzielenia?

Właśnie geniuszu! Tu jest klucz! Jeszcze trochę, i dotrze! Jak dostanę null to od razu wiem, że to nie ma nic do dzielenia! I tak ma być! Bo funkcja stwierdziła, że NIE DZIELI. A jak dostanę wartość dozwoloną, klasycznego double, to cholera wie, czy to jest wynik, czy błąd, czy kiepski dowcip.

A jak dostanę wyjątek to już w ogóle jest poezja, bo nie muszę wróżyć z fusów albo analizować cudzych wizji i cudzych widzi mi się - bo nawet kompilator mnie nie przepuści, tylko natychmiast oznajmi głośno i wyraźnie: co może pójść nie tak, w której funkcji, i że mam się na to przygotować. Tak jest - pisząc sensowną nazwę Exception'u nawet zobaczę CO SIĘ STANIE, bo nazwy klas mają być znaczące.

Z drugiej strony... jeśli uważasz, że try {... } catch(cause) { ... } to kontrola przepływu, to rozumiem skąd twoje niezrozumienie wynika. Jeśli na diagramach UMLowskich uwzględniasz try-catch i próbujesz catche uwzględniać w "normalnym cyklu przepływu sterowania w programie"... to mam wrażenie, że tylko krok cię dzieli od robienia if'ów za pomocą pętli while:

while( warunek ) {
   // ...
   break;
   }

sorry, mam wrażenie, że z "programistą" na takim poziomie właśnie dyskutuję.

Nie wiem, czego nie rozumiesz w zdaniu o poprawności dzielenia przez 0 dla doubli.

Nie wiesz, bo najprawdopodobniej tak samo jak nie odróżniasz if-else (bloki decyzyjne) od try-catch (bloki obsługi błędów) nie potrafisz odróżnić dziedziny od implementacji (co mnie obchodzi, że IEEE pozwala dzielić przez 0, jeśli takiej operacji funkcjonalnie przeprowadzać nie mam prawa).

0

Dzielenie całkowite przez zero powoduje wyjątek, a więc generalnie rzecz biorąc różne zachowanie intów i doubli łamie LSP :]

1

a owszem - jest też taki inny dowcip, jakby się zastanowić... dzielenie przez 0 tak świetnie jest well-defined, że nawet "twórca i znawca IEEE" nie zwrócił uwagi, że wyniki może dać dwa. I wszędzie trzeba się zabezpieczać nie przed jednym Infinity, ale przed dwoma. iloraz(4, 0) i iloraz(-4, 0) ...

Żeby było śmieszniej, nieskończoność NALEŻY do zbioru poprawnych rozwiązań. Jeśli ktoś mi wywali komunikat o dzieleniu przez zero po poniższej operacji, to już z całą pewnością będzie należało zamordować...

double c = iloraz(100, 10*Double.MIN_VALUE);

Efekt ? Prawidłowa obsługa genialnej podziel zwracającej magic number będzie wyglądać jakoś tak:

double x = 1;
double y = 10e3*Double.MIN_VALUE;
double c = iloraz(x, y);

System.out.println("c=" + c );
System.out.println("błąd? " + (c == Double.POSITIVE_INFINITY) );
System.out.println("zero? " + (y == 0) );

if( (Double.POSITIVE_INFINITY==c) || (Double.NEGATIVE_INFINITY==c) ) {
    if(y == 0) {
        // ROTFL - musimy i tak porównać sami z zerem, bo funkcja
        // zwraca kod błędu w tak kulawy sposób, że niedomiaru od dzielenia przez 0
        // nie odróżnimy
        System.out.println("błąd logiczny -  bo dzielenie przez zero");
    } else {
        System.out.println("błąd techniczny - bo wynik dzielenia zbyt duży");
    }
}

klękajcie narody, no to się nazywa sensowna prezentacja błędu! Dosłownie - kolejny dzień wróżenia z fusów czas zacząć. podwójny if, z or'em w środku na dodatek.

W przypadku zwykłego, normalnego podejścia do sprawy (wyjątki) odróżnienie technicznego błędu od logicznego już jest. Logiczny wyrzuci do catcha, techniczny na razie nas nie wyrzuci... ale skoro już wiemy, że coś takiego nastąpić może - funkcja w wersji 2.0 może spokojnie rzucać drugi rodzaj wyjątku. Nawet w wersji z null'em, która jest ostatecznością wiemy na czym stoimy: null to złamanie "naszych" reguł, nieskończoność to złamanie reguł technicznych.

Nie chcę myśleć jakby wyglądała obsługa czegoś takiego:

double x =  iloraz(a, b)+iloraz(c, d)+iloraz(e, f);
System.out.println("wynik=" + x );

W przypadku wyjątków można to normalnie tak zapisać - wyjątki nas wyrzucą do najbliższego catch ładnie zaznaczając przy której instrukcji to nastąpiło. Nawet ta nieszczęsna wersja null'owa nas wyrzuci za pomocą NPE wtedy kiedy trzeba. A co zrobi "magic number" ? A no cholera wie - na ekranie może nam się pojawić wszystko, +/-Infinity a nawet NaN, i cholera będzie wiadomo dlaczego coś takiego się pokazało. No albo... albo sobie można if'ów parę dowalić... no cudownie - jakieś 20 linii zagnieżdżonych if-else-if z or'ami w co drugim - właśnie o takich wyzwaniach marzę każdego dnia. Bo napisać po ludzku throw się nie chciało.

0

@Ranides, grzmisz, obrażasz, a Twoje rozwiązania nie spełniają warunków.

Niestety moja metoda musi zwracać wartości double

Pytanie, po co taka funkcja? Na razie wymyśliłem jedno zastosowania: (prócz oczywistego, bo tak chce prowadzący zajęcia) piszemy kalkulator,
konwertujemy wyrażenie wpisane przez użytkownika do postaci ONR, zamieniając dodatkowo / na iloraz. Uwolni nas to od konieczności sprawdzania
przy każdym działaniu czy to przypadkiem nie jest dzielenie, a jeśli jest, to czy dzielnik jest różny od zera. Takie rozwiązanie (z użyciem wyjątków) będzie niedobre
jeżeli kalkulator dopuszcza używanie funkcji matematycznych. Funkcje log, acos, sqrt, .. nie rzucają wyjątkami w przypadku argumentu spoza dziedziny,
one zwracają NaN.
Funkcja spełniająca warunki powinna wyglądać tak:

private double iloraz(double a, double b) throws IlorazException
{
    try
    {
        if(b==0)
        {
            throw new IlorazException("dupa");
        }
    }
    catch(Exception e)
    {
    }
    finally
    {
        return a/b;
    }
}
0

@Ranides, z czym Ty walczysz? Fragment pierwszego postu: która w razie gdy ktoś będzie dzielił przez 0 wyświetli stosowny komunikat. Autor nie sprecyzował czy program ma GUI, stąd propozycje System....., (a nie cosTam.setText()).

2

Z czym istocie walczę? Z podejściem:
A) return 999.999
B) return Infinity

Bo to należy do dziedziny wyników. Gdzieś tam po drodze zwróciłem uwagę, że 1) checked, 2) unchecked 3) null,..
a w trakcie dalszej rozprawy padło też 4) NaN, bo to również przynajmniej od razu widać, że "nie wynik dzielenia", i większość funkcji jest na NaN uczulona.

Walczę też może z tym:
Q: "jak sygnalizować?"
A: "sprawdzaj, czy IsInfinity..." - ani odpowiedź na pytanie, ani sensowna

więc tak @bo - NaN też jest fajny. Trzyma się konwencji kilkunastu wbudowanych funkcji najniższego poziomu. (1), (2) ,(3) , (4)... w różnych sytuacjach zależnie od kontekstu - luz. Ma wady, ale w uzasadnionych przypadkach (żeby np trzymać konwencję innych funkcji towarzyszących) przeżyć idzie. Za to (A) albo (B) zawsze będą horrorem, to jest, ekhem... "zasrana magia" i takich rzeczy się nie robi.

1

Wycofujesz się. Atakowałeś dość brutalnie próby wypisania na ekran, ale autor wątku wyraźnie tego chciał.
Nie reagujesz na zwrócenie uwagi, że żadna z zaproponowanych przez Ciebie funkcji nie spełnia wymagań, natomiast chamsko atakujesz innych.
Powołujesz się na zdanie

Czy jest jakaś możliwość zwrócenia informacji że nie wolno dzielić przez zero

Nie wiadomo co autor miał na myśli, na pewno nie to co napisał. Informacji że nie wolno dzielić przez zero nie trzeba zwracać,
może chodzi o informację, że była próba dzielenia przez zero.
Wybór jednej z możliwości:

private double iloraz(double a, double b) throws IlorazException
{
    try
    {
        if(b==0)
        {
            throw new IlorazException("dupa");
        }
    }
    catch(Exception e)
    {
    }
    finally
    {
        return a/b;
    }
}
//----
private double iloraz(double a, double b)
{
    return a/b;
}
//----
private double iloraz(double a,double b)
{
    if(b==0)
    {
        return Double.NaN;
    }
    return a/b;
} 

powinien zależeć od ewentualnych zastosowań tej funkcji. A dyskusja o wyższości jednej z nich nad pozostałymi, jest, imho, bez sensu.
P.S.

Mnie obchodzi, że każdy matematyk zawału dostanie na widok 10/0 = INFINITY
Zapewniam Cię, że zdecydowana większość
matematyków (nie nauczycieli matematyki) nie dostanie zawału.

0
bo napisał(a)

Funkcja spełniająca warunki powinna wyglądać tak:

private double iloraz(double a, double b) throws IlorazException
{
    try
    {
        if(b==0)
        {
            throw new IlorazException("dupa");
        }
    }
    catch(Exception e)
    {
    }
    finally
    {
        return a/b;
    }
}

WTF? Uruchomiles chociaz ten kod? Po co to rzucanie wyjatku, ktore jest tlamszone przez return w finally? Pomijam fakt ze nawet taki eclipse podkresla ostatnie linijki o komunikuje:
'finally block does not complete normally'

1

bogdans, żeby długo nie pieprzyć od rzeczy:

wskaż mi jedną funkcję z modułu Math albo statyczną metodę klas Number, Integer, Float et consortes, która robi bez opamiętania po ekranie.
nie wskazałeś? prosty wniosek: napierdalania po ekranie nie umieszczasz w funkcjach matematycznych tylko delegujesz do innej sekcji. finito. kropka.

w funkcji printf albo innych toString nie liczysz wyznaczników, per analogiam w funkcjach liczących wyznaczniki nie printfujesz ani nie sklejasz stringów.

wskaż mi z tej swojej większości chociaż jednego matematyka, który twierdzi, że Inifinity należy do R - bo tylko wtedy zapis będzie poprawny. Ja wiem, że tytuł doktora albo prof daje niektórym poczucie, że mogą bredzić od rzeczy - a mimo to, nie sądzę, żeby znalazł się chociaż jeden z tej twojej "większości" który takie brednie nawet pijany w trupa będzie bełkotał. Chociaż fakt - znałem już geniuszy, co widząc program w C twierdzili, że to "nie jest C" - bo pierwszy raz digraphs na oczy zobaczyli. To pewnie i ułomnych z podstaw algebry by znalazł, co nie wiedzą, jak brzmi definicja dzielenia (podpowiem terminy: ciało, element odwrotny, zero). Jak ktoś mi zacznie powoływać na zapisy w stylu 0/0 z analizy to łaskawie zdradzę sekret: tylko małpa jest w stanie twierdzić, że to są 3 symbole, a środkowy oznacza dzielenie. To jest JEDEN symbol, w dodatku używany w innej dziedzinie niż R

wskaż mi chociaż jeden kompilator javy, który oznajmi, że nie mogę napisać:

double function() throws Exception() { throw .... }
....
double n = function();

tylko wtedy twierdzenie będzie miało sens, że funkcja rzucająca wyjątki jest zła / nie spełnia wymagań / bo "nie zwraca double". Tak się składa, że typ zwracanego wyniku ma się nijak do deklaracji throws, a każdy kto próbuje jedno z drugim mieszać zwyczajnie bredzi. Zupełnie tak samo, jak każdy kto miesza obsługę błędów z logiką nie pisze tylko losowo tłucze w klawiaturę.

parser ONP zwracający NaN gdzie popadnie... sprawa jest prosta - albo napiszesz coś, co jako-tako działa dla poprawnych danych, a w przypadku błędnego wyrażenia zwróci "cholera wie co, i cholera wie dlaczego"... albo od razu nauczysz się, jak obsługiwać i propagować sytuacje, które miejsca mieć nie mają. Gdyby jakikolwiek parser albo lexer mi się zachowywał w taki sposób, to człowiek by nie był pewny dnia ani godziny i siedziałby 8 godzin dziennie nad telefonem i debuggerem - na zmianę. Jaki jest sens w połowie obliczeń wypisywać "nie mogę dzielić"... a następnie kontynuować obliczenia na jakimś abstrakcyjnym wyniku cząstkowym? Debilzm pierwszej wody - skoro "nie można dzielić, to nie można" - wylot + informacja o EvaluationError at token xxx before yyy - allelluja i do przodu.

W zasadzie - to nie wiem czasem, czego oni was tam uczą. Randomy pisać ?

ps. niezalogowany - nie będzie brzydkiego "napisu przy grupie"

0
Ranides napisał(a)

Właśnie geniuszu! Tu jest klucz! Jeszcze trochę, i dotrze! Jak dostanę null to od razu wiem, że to nie ma nic do dzielenia! I tak ma być! Bo funkcja stwierdziła, że NIE DZIELI. A jak dostanę wartość dozwoloną, klasycznego double, to cholera wie, czy to jest wynik, czy błąd, czy kiepski dowcip.
tylko wtedy twierdzenie będzie miało sens, że funkcja rzucająca wyjątki jest zła / nie spełnia wymagań / bo "nie zwraca double". Tak się składa, że typ zwracanego wyniku ma się nijak do deklaracji throws, a każdy kto próbuje jedno z drugim mieszać zwyczajnie bredzi. Zupełnie tak samo, jak każdy kto miesza obsługę błędów z logiką nie pisze tylko losowo tłucze w klawiaturę.
Hmm, idąc dalej tym tropem, rozumiem, że taką funkcję też uważałbyś za poprawną:

Object iloraz(double a, double b) {
    if (b != 0) {
        return a / b;
    } else {
        return "japierdole";
    }
}

Oświecę cię, to zjeb*** rozwiązanie.

Ranides napisał(a)

Nie wiesz, bo najprawdopodobniej tak samo jak nie odróżniasz if-else (bloki decyzyjne) od try-catch (bloki obsługi błędów) nie potrafisz odróżnić dziedziny od implementacji (co mnie obchodzi, że IEEE pozwala dzielić przez 0, jeśli takiej operacji funkcjonalnie przeprowadzać nie mam prawa).
Jedno z nas na pewno nie potrafi.
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, bo niechcący dzielna może być zerem. Bo DANE SIĘ WALIDUJE, A NIE NA PAŁĘ WOŁA FUNKCJĘ, KTÓRA I TAK SIĘ wyrzuci. Dlatego też np. Math.sqrt zwraca NaN dla liczb ujemnych, nawet jeśli to nie jest to, czego oczekiwałeś (chociaż JEST TO WYNIK JAK NAJBARDZIEJ POPRAWNY). W każdym razie nie rzuca żadnym zjebanym SqrtException (w dodatku checked). Jeśli dane są niepoprawne, to zwyczajnie się to sprawdza, bo nie jest to żadna zasrana sytuacja wyjątkowa. 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 dla ZAWSZE POPRAWNEGO KODU (bo taki jest, dopóki nie próbujemy dzielić przez 0).

Ranides napisał(a)

a owszem - jest też taki inny dowcip, jakby się zastanowić... dzielenie przez 0 tak świetnie jest well-defined, że nawet "twórca i znawca IEEE" nie zwrócił uwagi, że wyniki może dać dwa.
(...)
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. Toteż (jeśli mamy funkcję iloraz(x, y) = x / y):

double a = 10;
double b = 0;
double c = iloraz(a, b);
if (Double.isInfinite(c)) {
    System.out.println("dupa, chociaż wszystko ok");
}

A nie żadne ify, ory i c**** wie co ty tam jeszcze sobie wymyślisz.

Poza tym, wielki krucjatorku, albo niedokładnie czytasz, albo się trochę poddajesz. Wciąż nie odpowiedziałeś na to:

iooi napisał(a)

I mówi to ktoś, kto pokazał kod, który nawet stacktrace wyjątku wypisał na stdout.
Bo w sumie część twojego srania jest o wypisywaniu.

Na koniec:

Prosta metoda dzielenia dwóch liczb
Jak widać, nie taka prosta ;d

3

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.
0

@romperstomper
Masz dużo racji. Kod jest poprawny, kompiluje się bez ostrzeżeń i wykonuje bez błędów. Kod jest bez sensu, bo rzuca wyjątek, który jest "przykrywany". Pokazuje to tylko, że nie da się napisać funkcji iloraz, która zawsze zwraca double, jednocześnie (żądanie Ranidesa) przez rzucenie wyjątku informuje, że była próba dzielenia przez zero.

0

Wiadomo ze sie nie da. Myslalem ze jednak probujesz tego dokonac ;d
A ranides, hmm, moze jednak przemilcze. Szczegolnie ton wypowiedzi.

0

@Ranides, Ty cały czas o jakiejś idealnej funkcji iloraz, autor wątku napisał

Witam, mam mały problem, chcę zrobić metodę iloraz, która w razie gdy ktoś będzie dzielił przez 0 wyświetli stosowny komunikat. Niestety moja metoda musi zwracać wartości double, i w przypadku podanego kodu zwróci "Dzielnikiem jest zero, Iloraz: Infinity".
Czy jest jakaś możliwość zwrócenia informacji że nie wolno dzielić przez zero w obrębie tej metody, czy jest na to jakiś inny sposób?

A ja o takiej jak opisano powyżej.
P.S Jak matematyk zobaczy zapis 3/0=Infinity, to nie zostanie zawału, bo przyjmie, że wynik dzielenia jest w dwupunktowym uzwarceniu R.

0

jak ktos pisze jakies midleware, logike lub jakies komponenty np ten nieszczesliwy iloraz to oczywiscie ze trzeba w razie nie dozwolonej operacji rzucic wyjatkiem. Zawsze przy tworzeniu uzytkowej aplikacji dojdziesz do sytuacji ze bedziesz musial ten wyjatek (czy twoj czy przejety skads indziej) przeksztalcic na cos bardziej ludzkiego, bo w koncu jakis uzytkownik koncowy bedzie musial w prosty czytelny sposob wiedziec co spieprzyl. Metoda main w przykladzie co prezio napisal, jest tu takim ostatnim przystankiem gdzie trzeba cos takiego zrobic. Raczej jakas pani Ala nie bedzie chciala widziec calego stacka wyjatku a tylko jakas informacje a ty Ranides na sile chcesz jej wcisnac caly ten stack.

1

Raczej jakas pani Ala nie bedzie chciala widziec calego stacka wyjatku a tylko jakas informacje a ty Ranides na sile chcesz jej wcisnac caly ten stack.

ranides napisał(a)

I żeby było śmieszniej - ten println nie rzuca stacktrace, tylko czytelny opis błędu: "IlorazException: dzielenie przez zero nie lubieć ja".

Metoda main w przykladzie co prezio napisal, jest tu takim ostatnim przystankiem

ostatnim przystankiem jest koniec głównego wątku, a nie środek funkcji matematycznej

Kod jest bez sensu, bo rzuca wyjątek, który jest "przykrywany". Pokazuje to tylko, że nie da się napisać funkcji iloraz, która zawsze zwraca double,

spróbuj skompilować kod:

public double dummy(double a) {
        if(b = 77.0) return 55.0;
    }

przeczytaj błąd. a potem skompiluj

public double dummy(double a) {
        if(b = 77.0) return 55.0;
        throw new IllegalArgumentException();
    }

jassme - tak się "nie da", że odwołanie do autorów javac ci tylko pozostaje, żeby kompilator do twoich wyobrażeń przerobili, albo przerobić własne wyobrażenia, które nie mają nic wspólnego z pojęciem: "funkcja zawsze zwracająca double". Kompilator z definicji nie pozwala na pisanie funkcji, które "nie-zawsze" zwracają. Twój problem, że nie rozumiesz jaka definicja jest obowiązująca.

.S Jak matematyk zobaczy zapis 3/0=Infinity, to nie zostanie zawału, bo przyjmie, że wynik dzielenia jest w dwupunktowym uzwarceniu R.

robiąc takie "przyjęcie" na obronie pracy to obrona by się skończyła szybciej niż zaczęła. "matematyk" by został wywalony z hukiem, tak samo jak studenciak pierwszego roku, który na szeregach sobie l'Hopitala stosuje. Nie możesz ot tak sobie przejść z N do R, albo R z rozszerzonego R - bo tak ci wygodnie - bez bardzo obszernego komentarza. Albo jawnego przyznania, że niepoprawne wyrażenie wskutek baaardzo daleko idącego skrótu myslowego przyjmujesz "se" za poprawne.

Matematyka to nie KK, tutaj ja nie muszę nic w Ci "wierzyć", nie mogę też sobie czegoś "przyjmować bo tak". To jest formalizm a nie malowanie bławatków.

Na ten moment okazuje się, że należy zrewidować

  • bibliotekę języka Java - wszystkie funkcje do prowadzenia obliczeń wysokiej precyzji rzucają ArithmeticException
  • standard IEEE - który mówi, że division by zero to exception
  • konwencje w jednym z najbardziej dojrzałych projektów: apache.commons
  • kompilator języka, żeby "funkcja throwująca była traktowana jako nie-zwracająca-zawsze"
  • definicję dzielenia - ponieważ w rozszerzonym R nie jest ona możliwa do wykorzystania, żeby stworzyć ciało

I wtedy to wy macie rację. Więc szykujcie się do przepisania kilku standardów, kilkudziesięciu definicji i przepisania ilości kodu mierzonego w milionach linii. A dopóki sobie z tym nie poradzicie, to niestety - macie tylko jedną opcję:

A ranides, hmm, moze jednak przemilcze. Szczegolnie ton wypowiedzi.

to jest dobry wybór. Milcz, gdy nie masz nic sensownego do powiedzenia, czytaj dokumentację, standard, i podręcznik do algebry. Tam jest napisane milszym, chociaż trudniejszym do załapania tonem. Do ciebie należy wybór, czy wolisz walczyć z nieprzystępnością, czy z nieuprzejmością. Ślubu z żadnym brać nie planuję, nie widzę więc celowości w dziubkowaniu tutaj.

0

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.
Przede wszystkim po stronie konsumenta. Ofc, taki kod może być, jeśli już zaprzęgać do tego wyjątki:

double iloraz(double a, double b) {
    if (b != 0) {
        return a / b;
    } else {
        throw new ArithmeticException("zjebales");
    }
}

main() {
    double a, b;
    if (b == 0) {
        println("b = 0");
    } else {
        println(iloraz(a, b));
    }
}

Jednak ty będziesz płakał, że mamy tutaj podwójne przyrównanie do zera (co już wcześniej robiłeś). Ale nie twoje debilne żonglowanie checked exceptionami i sprawdzanie nimi, czy b przypadkiem nie było równe 0.

Autor spytał się, czy jest jakaś możliwość zwrócenia informacji o nieprawidłowości dzielenia przez 0. Bo mu odpowiedział, że takie dzielenie dla doubli jest poprawne, może jedynie sprawdzać, czy dzielnik jest równy zero. Ty jedynie powtórzyłeś to w swoim poście z niepoprawnym i idiotycznym zastosowaniem wyjątków, szczekając przy tym na wszystkich dookoła. Autor nie pytał, jak sprawdzić, czy b = 0. Bo to, do kur***, umiesz nawet ty.

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
Z całą pewnością może, jeśli taka jest jego implementacja. I z całą pewnością nie jest to wyjątek. W takim razie - musi być to rezultat poprawny.

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.
Właśnie że nie cichy. Bardzo głośny błąd, bo nie przechwycam wyjątku, który wcale nie jest wyjątkiem, a karygodnym błędem.

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 kur*** 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ć");
Że wynik jest dobry, ale nie możemy wypisać na wyjście "Infinity", więc wsadźmy go sobie w dupę.

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.
Jest to komunikat informujący o błędzie, lol.

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.
Wiesz, ale sam równie zjeb*** rozwiązanie proponujesz?

1 użytkowników online, w tym zalogowanych: 0, gości: 1