Witam.
Chciałbym się dowiedzieć jaka jest różnica, gdy w bloku catch użyję catch(Exception ex) zamiast np. catch(FormatException ex) w obu przypadkach wyrzuca mi
System.FormatException: 'Input string was not in a correct format.'.
Kiedy wyjątek jest nieobsługiwany(unhandled) oraz obsługiwany? Jaka jest różnica?
- Rejestracja:ponad 5 lat
- Ostatnio:około 2 lata
- Postów:10
0
- Rejestracja:prawie 7 lat
- Ostatnio:5 miesięcy
- Postów:273
2
@elopadre: Klasy wyjątków dziedziczą po sobie. Jak weźmiesz wyjątek z samej góry hierarchii dziedziczenia a będziesz chciał złapać jeszcze inne wyjątki to pierwszy catch (Excption ) wyłapie wszystkie jednocześnie. W małych programach to nie ma znaczenia .
- Rejestracja:około 9 lat
- Ostatnio:około 2 lata
1
Zimny Krawiec napisał(a):
W małych programach to nie ma znaczenia .
Ale lepiej uczyć się i na małych programach porządku. :)
- Rejestracja:ponad 5 lat
- Ostatnio:około 2 lata
- Postów:10
0
A co do rzucania wyjątkiem to dobrze rozumiem, że np. pisząc metodę w serwisie która przyjmuję jakiś model i wrzuca go do bazy danych sprawdzamy w niej np.
if(model == null){throw new NullReferenceException("Model object is null.")}
To potem wykorzystując tą metodę w kontrolerze musimy umieścić ją w bloku try a następnie gdy dany wyjątek zostanie wyrzucony w bloku catch(NullReferenceException nREx) robimy np. przekierowanie do widoku z opisem wyjątku.
edytowany 4x, ostatnio: elopadre
- Rejestracja:ponad 8 lat
- Ostatnio:około 6 godzin
- Postów:925
0
Raczej ArgumentNullException. A najlepiej unikać rzecania wyjątkami. Dlaczego ten model może być nullem, z powodu aktywności usera? To walidacja powinna to załatwiać. A jak nie to możesz zwracać jakiś Result z metedy i na wyjściu przemapowac.
- Rejestracja:około 9 lat
- Ostatnio:około 2 lata
0
kzkzg napisał(a):
Raczej ArgumentNullException. A najlepiej unikać rzecania wyjątkami. Dlaczego ten model może być nullem, z powodu aktywności usera? To walidacja powinna to załatwiać. A jak nie to możesz zwracać jakiś Result z metedy i na wyjściu przemapowac.
Nie najlepiej -- bo to zależy od języka, ale i (co ważniejsze!) od modelu programowania i wytycznych. Wyjątki nie są po to,by ich unikać, tylko po to, by ich sensownie używać. Inaczej by ich nie było...
kzkzg
Zależy od języka powiadasz :) To w. NET jest dobrze rzucać czy nie dobrze?
koszalek-opalek
@kzkzg: Nie znam się. :)
- Rejestracja:około 14 lat
- Ostatnio:3 dni
- Lokalizacja:Bk
- Postów:480
1
elopadre napisał(a):
A co do rzucania wyjątkiem to dobrze rozumiem, że np. pisząc metodę w serwisie która przyjmuję jakiś model i wrzuca go do bazy danych sprawdzamy w niej np.
if(model == null){throw new NullReferenceException("Model object is null.")}
To potem wykorzystując tą metodę w kontrolerze musimy umieścić ją w bloku try a następnie gdy dany wyjątek zostanie wyrzucony w blokucatch(NullReferenceException nREx)robimy np. przekierowanie do widoku z opisem wyjątku.
Moim zdaniem nie powinno sie wykorzystywac wyjatkow do sterowania jak to zrobiles.
Jezeli if'em sprawdzasz null to w bloku tego if'a powinienes w jakis sposob oprogramowac co w takim przypadku program ma robic.
Nawet nie jestem pewien czy objecie calego tego if'a jak go zrobiles blokiem try ma sens. Raczej zastapienie if'a blokiem try to dobry pomysl.
Generalnie wyjatki traktuj jako cos niespodziewanego co normalnie wg Ciebie nie powinno sie wydarzyc. Czytaj dokumentacje uzytych metod i jezeli ktoras moze rzucic wyjatek albo oprogramuj/zabezpiecz ten przypadek kodem kompleksowo, albo obejmij ten kod w bloku try i w kolejnych catch'ach obsluguj je tak aby miec pewnosc ze program utrzyma stabilnosc ale tez info co sie wydarzylo.