Což o to leaky mi kontrolují různé nástroje a nikdy jsem si žádného nevšiml. Asi zpravidla proto, že většinou jde o objekty, u kterých se předpokládá, že vzniknou na zásobníku. Má oblíbená architektura totiž vypadá takto
1. objekt co vlastní zdroj
2. objekt co s ním manipuluje (manipulant - builder)
Ten co vlastní zdroj, ten bývá často (ale ne vždy) alokován dynamicky. Naopak builder bývá výhradně na zásobníku. Builder většinou v destruktoru uvádí zdroj do konzistentního stavu, tak aby se případně dal používat s nějakým dalším builderem. Pokud by builder nedokázal zanechat zdroj v konzistentním stavu, tak je to fatal error a právě zde se má / měla hodit výjimka. Nedokážu si představit, že by se to zaignorovalo. Případný další builder bude pracovat s nekonzistentním zdrojem... NO WAY... to je těžkej malér.
Jediný co mě napadlo, jak by se to dalo řešit je výjimku forwardovat budoucímu builderovi, který ji výhodí v konstruktoru. Znamená to ale, abych si u zdroje vedl jeho stav, nebo ještě jednodušeji, abych výjimku zachycenou v destruktoru místo vyhození uložil do objektu držící zdroj.
Ani to neřeší problém 100%. Pokud mám pool zdrojů, třeba databázových spojení a já uložím do poolu nekonzistentní zdroj (protože jsem se nedozvěděl, že je nekonzistentní, žádná výjimka nevylítla), tak i forwardovaná výjimka vylítne tomu, kdo další takový zdroj vytáhne z poolu. A ohlásí chybu ... to může být třeba další request na serveru... chyba se ohlásí tedy někomu, kdo za to nemůže... NO WAY!
Takže mě ještě napadl další workaround. Dodělat do všech možných zdrojů, které mám, kromě funkce forwardování výjimky, taky funkci na kontrolu integrity (checkIntegrity()). Tato funkce by mohla hodit forwardovanou výjimku. Před uložením do poolu by se to zavolalo a pokud by výjimka vylítla, tak by se zdroj rovnou zlikvidoval a do poolu by se nevracel. Bohužel, vracení do poolu je realizováno v destruktoru
Takže onu výjimku si mohu maximálně strčit ... někam do logu.
Ještě příklad. Když mi v destruktoru transakce falíruje operace rollback, už nemám šanci se to dozvědět (a to ani v případě, že neletí žádná výjimka) a maximálně při vracení mysql spojení do poolu mohu ověřit, jestli tam není někde forwardovaná výjimka a pokud ano, tak ji zalogovat a z databáze se odpojit ... snižit počet aktivních spojení z databází, pool pak vyrobí novou konekci.
Uff a to je kvůli tomu, že mi selhal rollback