Witam,
jestem całkowitym noobem jesli chodzi o programowanie.Ostatnio staram się pojąć język c# - z jednej strony bym chciał to umieć, z drugiej muszę to zaliczyć w szkole. Przerabiam temat wraz z ksiązką którą dostałem na wykładzie, no ale do rzeczy - Mam pytanie raczej czysto teoretyczne odnośnie obsługi wyjątków. Po co konkretnie to sie stosuje? ogolnie spr wyjątki dzieląc przez 0. Bez ich obsługi wywalało z programu, z ich obsluga działo się to samo z tym,ze najpierw wyskoczył komunikat o błędzie.Generalnie to samo mógłbym uzyskac stosując if prawda? jesli dzielnik = 0 to ma wyskoczyc komunikat i zamknąc program. Czy się myle? A wiec w skrócie, czy to jest potrzebne? Czy tego uzywa sie w praktyce? Szczerze to czytając te ksiązki o c# rozumiem większość pojęć, jednak często zwyczajnie zadaje sobie pytanie 'no i co teraz z tym? do czego mi się to przyda?' więc chciałbym o przyklady z zycia;p
- Rejestracja:około 14 lat
- Ostatnio:ponad 10 lat
- Postów:126
C# - Rejestracja:prawie 14 lat
- Ostatnio:ponad 11 lat
- Postów:106
Dzielenie przez zero to tylko jedno ziarnko piasku na plaży wyjątków. Wyjątek może powodować praktycznie wszystko. Może to być źle sformatowany tekst, zła ścieżka pliku, pusta wartość. W tym momencie ciężko tak z miejsca powymieniać, ale wystarczy trochę 'poprogramować' i od razu to zauważysz. Weźmy na przykład serwer komunikatora. Bez obsługi wyjątków wystarczyłby jeden błąd i pada cały serwer. Dzięki temu program staje się odporny (w pewnym stopniu) na ludzi, którzy próbują umyślnie te błędy wywołać. Nie sposób spamiętać wszystkiego do sprawdzenia, a objęcie kodu obsługą wyjątków może Ci uratować tyłek. :)
- Rejestracja:prawie 14 lat
- Ostatnio:ponad 11 lat
- Postów:106
Dokładnie
- Rejestracja:około 14 lat
- Ostatnio:ponad 11 lat
A czy w C# jest tak jak w javie że kiedy w klauzuli catch Złapiemy 'nad-klasę' wyjątku to w następnej klauzuli próbując złapać 'podklasę' tej klasy wyjątku, to klauzula ta nie zostanie wykonana, bo wyjątek podklasy został złapany w nad-klasie ? I z tego powodu powinno się łapać od sub-klasy, bo nie wiadomo dokładnie co powoduje błąd ?
- Rejestracja:około 18 lat
- Ostatnio:12 miesięcy
Nie wiem dokładnie o co ci chodzi, ale raczej problemu, o którym mówisz nie ma. Raz, że wyjątek to obiekty i jeden wyjątek może zawierać w sobie podwyjątek, dwa, że sprawę ułatwia możliwość wyrzucenia tego samego wyjątku wyżej w catch. Dzięki temu tworzy się taki łańcuch, np. "nie można wczytać profilu -> nie można otworzyć pliku z profilem -> plik jest używany przez inną aplikację", gdzie każdy z wyjątków wyrzuca coraz to niższa warstwa aplikacji.
- Rejestracja:około 17 lat
- Ostatnio:około 13 godzin
- Lokalizacja:Wrocław
SzeWa napisał(a)
Generalnie to samo mógłbym uzyskac stosując if prawda? jesli dzielnik = 0 to ma wyskoczyc komunikat i zamknąc program. Czy się myle? A wiec w skrócie, czy to jest potrzebne? Czy tego uzywa sie w praktyce? Szczerze to czytając te ksiązki o c# rozumiem większość pojęć, jednak często zwyczajnie zadaje sobie pytanie 'no i co teraz z tym? do czego mi się to przyda?' więc chciałbym o przyklady z zycia;p
Na początku ucząc się składni języka faktycznie nie widzi się przydatności pewnych konstrukcji, zwłaszcza jeśli są one pokazane na prostych przykładach. (Ale tak jest chyba z uczeniem czegokolwiek.)
W przypadku dzielenia przez zero, które możesz przewidzieć to akurat wystarczy if. W zasadzie dobrze jest na etapie projektowania aplikacji przewidzieć jak najwięcej możliwych komplikacji, a wyjątki rzucać jedynie w sytuacjach (nomen omen) wyjątkowych. Tak naprawdę, robi się z tego całkiem niezła filozofia, kiedy użyć wyjątków, a kiedy if.
Przykład bardziej z życia - piszesz odtwarzacz mp3. Użytkownik wybiera do odtwarzania jakiś plik z dysku, ale ten plik tak naprawdę jest np. bitmapą ze złośliwie zmienionym rozszerzeniem. Tu można użyć wyjątku, który będzie łapany, jeśli plik nie będzie dał się odtworzyć.
Albo np. aplikacja, która odczytuje temperatury z termometru podłączonego przez port szeregowy i zapisuje do bazy danych, znajdującej się na innym serwerze w sieci lokalnej. Termometr ma zakres temperatur od -30 do +50 stopni, tymczasem nagle zwrócił wartość +200. Od razu widać, że jest nieprawidłowa, należy po jej odczytaniu rzucić wyjątek i zapisać do jakiegoś logu, że termometr zwariował. Podobnie, baza danych może nagle przestać odpowiadać. W tej sytuacji też należy rzucić wyjątek, który trzeba zalogować, bo przyczyny mogą być różne - np. ktoś skasował bazę z serwera, padła sieć, serwer był przeciążony. Wiedząc kiedy takie coś miało miejsce, można z administratorami ustalić co naprawdę się stało i wyciągnąć wnioski na przyszłość.
Albo np. jakaś firma przysyła Ci pliki CSV ustalonego formatu, w których są dane liczbowe, które Ty dla nich przetwarzasz swoim programem. W jednej z kolumn przewidziany jest typ danych int, tymczasem nagle znalazła się tam wartość spoza zakresu. W tej sytuacji procedura odczytująca i konwertująca dane powinna rzucić wyjątek, który pozwoli na stwierdzenie, że plik jest nieprawidłowy i np. nie należy go dalej przetwarzać, bo da fałszywe wyniki.
szypxx napisał(a)
A czy w C# jest tak jak w javie że kiedy w klauzuli catch Złapiemy 'nad-klasę' wyjątku to w następnej klauzuli próbując złapać 'podklasę' tej klasy wyjątku, to klauzula ta nie zostanie wykonana, bo wyjątek podklasy został złapany w nad-klasie ? I z tego powodu powinno się łapać od sub-klasy, bo nie wiadomo dokładnie co powoduje błąd ?
Tak, w C# możesz stosować wiele bloków catch, z tym że muszą one być ułożone od najbardziej specyficznego do najbardziej ogólnego. Np.: DirectoryNotFoundException, IOException, Exception.
- Rejestracja:prawie 14 lat
- Ostatnio:około 6 godzin
- Postów:2512
Przykład jeszcze podam bardziej abstrakcyjny kiedy wyjątki się przydają. Załóżmy, że mamy funkcje A,B,C,D,E,F, przy czym A wywołuje B, B wywołuje C, C wywołuje D itd.
bool A()
{
try
{
B();
return true;
}
catch(Exception e)
{
log.Error(e.Message);
return false;
}
I teraz w funkcji F stwierdzasz, że wystąpił błąd i nie ma sensu dalsze wykonanie (lub wystąpił błąd, którego nie przewidziałeś).
void F()
{
if (nieMaSensuDalejWykonywac)
{
throw new Exception("Ewakuacja");
}
}
W takim przypadku od razu wrócisz do funkcji A i oczywiście znajdziesz się w bloku catch
