Je chybně zadaná vstupní hodnota uživatelem výjimka nebo normální součást běhu programu? rubrika: Folklór

14 rmaslo
položil/-a 23.1. 12:28
 
upravil/-a 25.1. 3:09

Jedna taková spíše filozofická ... spíše průzkum názorů než, že bych očekával nějakou jednoznačnou odpověď. Tak se pls. nehádejte.

Výjimky ošetřují chybové stavy programu - ok definice jasná. Ale když třeba uživatel odešle formulář, kde třeba nevyplní povinné pole je to výjimka (ve smyslu způsobí Exception) nebo běžná součást běhu programu a preferovali by jste chybovou návratovou hodnotu?

--------------------------------------------------- Editace 25.1.2019
Omlouvám se, ale asi jsem tu otázku v rámci snadného pochopení zjednodušil až moc. "Chybně zadanými daty" myslím nejen nevyplněné pole, ale třeba i relativně složité věci, třeba ve smyslu uživatel zadal, že chce vyskladnit 5 ks, ale na skladě mám už jenom 4 protože tu pátou vyskladnil jiný uživatel mikrosekundu před tím. To znamená, že některé ty chyby mi vlastně může říci až db (duplicitní index) a nebo je dokonce můžu zjistit až ex-post a mohou mít za důsledek dokonce třeba i až rollback databáze (vyskladnění nelze realizovat, protože se jde do záporu).

Samozřejmě souhlasím s tím, že chybám uživatele je nejlepší předcházet už v prohlížeči a byla by hloupost třeba nezadanou hodnotu nechávat až na db (kde to vyhučí na not null), když v html máme attribut required. Na druhou stranu může se stát, že i takto jednoduchá chyba propadne někam hloubš, protože na klientovi někdo použil nějaký totálně zastaralý browser nepodporující requred, nebo si vypnul JS nebo si oeditoval zdroják, atd...
Proto jsem jako příklad dal to nevyplněné pole, ale myslel jsem tím spíš "kdyby náhodou prošlo přes vstupní kontroly v browseru", ale těžiště této otázky jsou složité chyby, odhalené až někde bussines logice a nebo i jednoduché chyby, které do bussines logiky propadnou nedopatřením.

Komentáře

  • rmaslo : Otázku jsem oeditoval, protože jsem ji neformuloval přesně a částí lidí nebyla dobře pochopena. 25.1. 3:12
odkaz Vyřešeno
16 Taco
odpověděl/-a 2.2. 16:48
 
upravil/-a 2.2. 16:50

Měj takovýto algoritmus:

foo = (a, b) ->
    ((a * a) / (a + b)) + b

Ne, že by to nešlo, ale je fakt, že řešit dělitelnost nulou se mi v této rovnici fakt nechce. Takže nechám výjimku probublat až někam vejš. Samozřejmě platí, že by neměla prosakovat implementace. Tudíž je správné, aby mi chyba probubla skrz několiv úrovní volání, ale vocuď-pocuď.

Nebo si doplním hlídání vstupů:

foo = (a, b) ->
    assert(a, "int")
    assert(b, "int")
    ((a * a) / (a + b)) + b

Když zavolám funkci se špatným parametrem tak je to fatální chyba programátora, a s ničím se nemazlím. Tedy okamžitě chcípnout a nesnažit se o žádné zachraňování. Čím dřív to zhebne, tím líp.

Pokud mám získávání vstupů, tak tam to je o konverzaci. Ten formulář například, konverzuje s uživatelem a nepustí ho, dokavad ho nepřinutí vložit validní data. Moc se nesetkávám s tím, že by tam nějaká výjimka byla potřeba.

Když ten validní formulář ukládám, tak to, že se mi to nemusí povést z nějakých interních důvodů je sice očekávaný stav, ale v praxi se často stává, že ukládáš do vícero zdrojů zároveň a v transakci, a tak je fajn si tu chybu odchytnout na jednom místě, rollbackonut, a vytvořit chybovou hlášku.

To platí i u tvé otázky ohledně business logiky. Je to chyba programátora? Nebo je to očekávaný stav? A záleží na tom?

Jsou třeba jazyky, které se bez výjimek zcela obejdou a všechno dělají pomocí monád (Maybe, Either, Optional). Takže to možná není tak úplně jednoznačné rozhodování.

Ale existuje jeden kategorický důvod pro výjimku. V jazycích, které neumí vynutit odebrání návratové hodnoty, tak lze výjimkou vynutit zpracování chyby.

Komentáře

  • Kit : Nečekal jsem, že s tebou někdy budu souhlasit. Právě se stalo. 2.2. 19:40
  • rmaslo : Porozuměl jsem tomu takto: Používat výjimky, nechat je probublávat, ale jenom na tu správnou úroveň. Ta "správná úroveň" je taková, aby to bylo na jednom místě a je to tam, kde se to má rollbacknout a tam se zároveň výjimka mění na návratovou chybovou hodnotu. Takže analýza výjimky se bude dělat jen 1x a použije se jak pro rozhodnutí zda udělat rollback a zároveň se ta analýza použije pro rozhodnutí o chybové hlášce. Ano, to je přístup, který pokládám za logický a bude mi vyhovovat (Samozřejmě nebrat to dogmaticky, závisí to na jazyku, atd...). V podstatě si myslím, že pro mé použití to ani není možno definovat o moc lépe a proto to označuji jako vyřešené :-). 3.2. 1:43
  • rmaslo : A speciálně jsi hezky zdůraznil jak nezáleží na tom jestli to, že přijde neregulární hodnota je chyba nebo vlastnost programu. Lze na to pohlédnout i z jiného úhlu mohu mít dvě aplikace se stejným modelem (něco jako MV1C1 MV2C2) v jedné nějaký vstup ošetřený mám v druhé ne, potom doručení neregulérní hodnoty z jedné je z hlediska modelu chyba a z druhé očekávaný stav. Ale modelu je to úplně jedno. Tohle rozhodně cítím stejně, akorát jsem to v původní otázce nesprávně formuloval a tím vznikly ty tanečky okolo toho, že to mám odchytit na klientovi. 3.2. 1:46

Pro zobrazení všech 13 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.