Diskuze: String nejde uložit do stringového pole
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Zobrazeno 20 zpráv z 20.
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Protože binCislo je string a pole je pole stringů. Ty děláš toto:
"Ahoj"[0] = {"Ahoj", "jak", "je?"}[0];takže musim rozdělit ten string na chary a ty chary hodit do pole?
V C# se nedají jednoduše měnit chary ve stringu, jsou read-only. Existuje však metoda ToCharArray na stringu.
binCislo si dokáži dle názvu představit, ale nevím, co je v pole, takže se špatně radí. Do celého programu pronikat nechci.
jj, dík moc. Pronikání do kódu chápu, nehci celý program
Proč máš vlastně v bloku try příkaz Console.WriteLine("chyba"); když to patří do bloku catch? Proč v bloku catch nemáš ošetření chyby, ale jen zobrazení chybové hlášky?
Do bloku try vložíš příkazy, ve kterých může dojít k chybě. Systémové či uživatelské. Pokud dojde k uživatelské chybě, vyvoláš ji ručně příkazem throw. Nepotřebuješ pak blok else, protože v případě výjimky se zbytek bloku try neprovede.
V bloku catch uděláš všechny operace, které se mají v případě výjimky provést. Vypsání uživateli nebo zápis do logu, ale hlavně napravení chyby nebo její vypropagování do vyšších vrstev.
Blok catch má v C# určitě nějaké parametry.
Máš štěstí, zrovna na to dopisuji tutoriál, za chvíli tu bude 
Nechápu proč nepoužil to tryparse,...
if (int.TryParse(nějaký string, out nějké int))
//Povedlo se - příkazy pro zdar,...int.TryParse() je jen berlička pro ty, kteří nechtějí používat výjimky. Pokud vím, tato metoda neumí pracovat s čísly v šestnáctkové soustavě.
Používání TryParse je určitě v pořádku, ale stejně tak není nic špatného na použití prostého try-catch. V try-catch je výhoda, že tam mohu nacpat parsování všech hodnot objektu a nemusím to ošetřovat po jedné. Naopak když potřebuji ošetřit 1 vstup, použiji TryParse. Je to jedno.
Bloků try není potřeba mnoho. V interních metodách je nepoužívám skoro vůbec. Raději nechám výjimku vybublat i mimo objekt. Často až do hlavního modulu, kde centrálně ošetřím vše, co se mezitím nezachytilo. U jednoduchých aplikací mám jen ten jeden.
O to víc práce si dám s parametry throw, aby obsahovaly dostatek údajů o vzniklé chybě. A také s blokem catch, který výjimky nesmí polykat, ale řešit.
Co myslíš tím řešit? Když se něco nepovede, tak na to uživatele upozorním a skončím. Když mi dá nesmyslné parametry z konzole nebo neexistující soubor, těžko to budu řešit jinak. Můžeš prosím uvést nějaký příklad?
Když se uživatel pokusí dělit nulou, tak přece neshodím celou kalkulačku, ale zobrazím nějakou reakci a pokračuji dál v aplikaci.
Když se mi nepodaří otevřít databázi, tak chybu zaloguji a poskytnu návštěvníkovi provizorní stránku.
Když z databáze nedostanu hledaný článek, do proměnných vložím náhradní obsah typu "článek nenalezen", přidám k tomu HTTP status 404, ale stránku přes šablonu normálně zobrazím.
Jinými slovy vždy jen zobrazuješ chybovou hlášku a skončíš.
V PHP na webu se vždy jen něco zobrazí a pak skript skončí, tak to nepřekrucuj.
Když budu třeba parsovat vstupní CSV a některý ze záznamů bude mít chybné pole, tak příslušný warning vypíši nebo zaloguji a jedu na další záznamy.
Tak web je velmi specifický díky klient-server architektuře. Nicméně chybová stránka 404 se dá chápat stejně, jako MessageBox v C#.
To CSV je dobrý příklad.
Zobrazeno 20 zpráv z 20.