Kdepak vyžužlal, koukej: http://www.antonis.de/qbebooks/gwbasman/onerror.html
Ale nebyl to zase úplně špatný soft, v NASA tím dokonce řídili robota na sváření raket!
Popravdě, zrovna toto je strukturovanější přístup, než například v céčku s návratovými kódy a jejich (ne)testováním :-) ERR+ERL jsou vlastně taková poor man alternativa k objektu Exception a vůbec, já na BASICu vyrost (Atari Basic + geniální Turbo Basic). Takže i ten robot jim asi chodil :-)
Mně zas připadá, že tzv. strukturované výjimky a všechny možné variace na toto téma jsou spíš nabourání strukturovaného přístupu. Někomu se kdysi zdálo, že testování chybových stavů znepřehledňuje kód. Že chyby jsou cosi druhořadého, trpěného vedle "hlavního" algoritmu. Podle mě je však chybový stav zcela normální situace, je to prostě jeden z mnoha stavů ve stavovém diagramu a tak by se s ním mělo také zacházet, tj. úplně normálně, jako s každým jiným stavem.
Všelijaké ty trapy apod. akorát vytvářejí paralelní strukturu pro chyby, která pak v praxi ale nekopíruje strukturu "hlavního algoritmu". Způsobuje separaci místa vzniku chyby od místa jejího zpracování, a to i vertikálně, přes úrovně jednotlivých vrstev, což je IMO zlo. Korektní zpracování chyby tímto stylem totiž totálně znepřehlední program, daleko víc než prosté testování návratové hodnoty. A tak se na to kašle, nechá se to zpropagovat až kdo ví kam a tam se teprve chyba řeší. Jenže takové místo je z hlediska struktury, tj. viditelnosti a rozsahu platnosti jednotlivých entit, izolované od místa vzniku. Vlastně už se tam nedá dělat nic, než jen vzít na vědomí, že "někde dole" vznikla chyba, u pečlivějších se dokonce ví, kde, ale v místě toho "trapu" už se na ni stejně nedá účinně reagovat.
71 Odpovědí
16676 Zhlédnutí