Práve, že ja neviem načo tam sú a ako sa majú použiť.
Ja zase nevim, co je cilem tveho snazeni. Udelal sis nejakou analyzu, ze ktere ti vylezl strom informaci o chybe, ktere chces nejak zakodovat a v aplikaci s nimi pracovat.
1. Prvni je taxonomie vyjimek, ktere rozsiris o ty informace. A tim to muze skoncit. Informace budou na urovni enumu a kodovat se nebudou a predavat se budou v instanci vyjimky. Pripadny chybovy kod lze metodou exception vyrenderovat. Cilil bezna prace s objekty.
2. Pokud by ta skladba informaci byla natolik heterogenni, ze by se spatne navrhovaly spolecni predkove vyjimek resp. by to bylo neprehledne ev. nesrozumitelne,
lze pouzit nejake zakodovani do jedne hodnoty, ktera by se pak predavala a pri praci se zase zpatky dekodovala apod (asi nema smysl uvazovat, ze by to nemusela byt nutne jedina hodnota, ale mohlo by jich byt nekolik)
3. Pokud by se informace musela/mela kodovat, zalezi, jakeho rozsahu jsou ty informace a jestli se ti vsechny vejdou treba do UInt64 s nejmensi jednotkou informace 1. byte. Pak je IMHO vhodne pouzit ten variantni record a enumy.
4. Pokud se nevejdou a bude nutne matlat bitiky, no tak si to budes muset rucne poskladat. Na jedne strane se nabizi reseni s enumy - tj. uplna silna typova kontrola v aplikaci tj. to, co jsem ti ted naznacoval naposledy, na opacne strane jsou normalni ciselne konstanty, to bude zrejme nejaky ten uplne prvni stary priklad error subsystemu.
A z toho se odviji, jake konstanty potrebujes nadefinovat. A definovat bys je mel tak, aby se vsechno definovalo jen jednou a aby kdyz zmenis nekde neco, aby se to automaticky promitlo do vsech ostatnich definic a nemusel jsi rucne prepisovat buhvi co vsechno.