Kdokolivale co kdyz je otevriSoubor cizi API funkce
Správná otázka. Mohu tě ubezpečit, že co autor to vlastní systém zabezpečení chyb. Vem si kteroukoliv third-part knihovnu a uvidíš to sám. Návratové kódy, failstate objektu, výjimky, errno, last error, atd. Třeba WinAPI používá lásterror (GetLastError). Pro MT aplikace má každý thread vlastní proměnnou lasterror, takže se thready neovlivňují. Novější WinApi (Com+) používají HRESULT, což je číslo, dost šíleně sestavené obsahující typ chyby, id chyby, kód výrobce a kód modulu. v Com+ každá funkce buď vrací nulu (Ok) nebo HRESULT, a jiný návratový hodnoty nemá. V Alias Maya se zase chyba vrací přes pointer nebo referenci na proměnnou předanou jako parametr volané funkce. Pak si musíš status zkontrolovat. A ještě ve WinApi, třeba MFC pro objekty CInternetConnection využává výjimky pro hlášení chyb připojení k internetu.
V zásadě tedy, pokud používám cizí Api, buď si napíšu wrapper (i DirectX doporučuju ten čas tomu věnovat). nebo odchytávám chyby knihovny na nejnižší možné úrovni a používám schránku chyb. Kód chyby do ní předávám bez změny s tím, že si poznačím, o jaký modul se jedná. Při chybě pak vracím false nebo failobject (nebo NULL), s tím, že nadřazený level najde důvod chyby ve schránce (vidíš, to je trochu obdoba varianty last error, s tím, že zacházení s chybou lze na všech úrovních libovolně přetěžovat.) Pokud third part knihovna vyhazuje výjimky, snažím se je všechny odchytávat na nejnižší úrovni a házet do schránky (a dále již provádět řízený návrat).
To že se v C++ často výjimky v API nepoužívají je řekl bych kvuli jejich problematické implementaci. Překladač (aspoň tedy MSVC) je stále implementuje tak, že výjimky mají dost velkou režii i když je vlastně nepoužíváš.
Tady vlastně Java má něco co ani nepotřebuje, ale hodilo by se to do C++. Povinná specifikace throw u funkcí. Zatímco Java si poradí i s výjimkami, které někdo neočekává (např. NullPointer) takže by ani seznam vyhazovaných výjimek nepotřebovala, v C++ by se to náramě hodilo. Kdyby překladač výužil znalost které volání způsobí kterou výjimku, pak by si podle mého názoru stack unwind mohl odpustit a výjimku by řešil už v době překladu. Prostě by výjimka nebyla nic, než speciální návratová hodnota z funkce, a program by jen hodnotu odtestoval a v případně pozitivního výsledku by provedl příslušnou čistící část funkce (jenž by překladač připravil už během překladu) bez nutnosti znát který objekty je nutné vyčistit (protože právě by překladač dopředu věděl, kde může nastat výjimka).
Je zajímavý, že
try{
Object1 a;
Object2 b;
Volani(); //haze vyjimku
}
catch(Vyjimka e)
{
e.VypisPopis();
}
lze dobře implementovat. jako
Object1 a;
Object2 b;
if ((Vyjimka e=Volani()).JeVyjimka) {e.VypisDuvod;return false;}
V prvém případě bude kód obohacen o několik instrukcí exception handlingu, v druhém případě o jeden test a čistící části, kterou zabezpečí příkaz return - kdyby se vědělo. že Volani vyhazuje výjimku Vyjimka, nemusel by přehladač vymýšlet žádný exception handling...
|
Registrace nového uživatele 
