> > Bardzo dobrze.
>
> To jakiś egzamin?

A jakbym normalnie i zgodnie z grupowymi zwyczajami zawalił Cię bluzgami, to by nie
był? :-)

> > Problem tylko w tym, że bardzo rzadko wiadomo, co z nimi zrobić.
>
> I jaki to ma związek z narzekaniem na jezyk C++?

Myślałem, że narzekamy na standard kodowania. Zakaz używania wyjątków jest dosyć
uniwersalny, niezależny od języka.

> > Często sprowadza się to do pokazania użytkownikowi komunikatu o błędzie.
>
> Nie wiem co to znaczy "często", ale u mnie raczej nie.

Interesujące. Ale to może (!) oznaczać, że obsługujesz wyjątki relatywnie blisko ich
wystąpienia.

> Ale przecież przykład miał służyć marudzeniu o bezdennnym dziadostwie C++.

Właśnie zgubiłem się, co hejtujemy. Jeśli C++, to niesłusznie (co za niespodzianka!),
bo zakaz wyjątków jest niezależny od języka.

> Taki mały przykłąd z systemu krytycznego:
>
> return a() && b() && c() && d() ... ;
>
> To jest emulacja wyjątku w środowisku gdzie wyjątków ma nie być. Wyszło
> jak zwykle. Parcie na systemy ograniczone wcale nie generuje lepszego
> jakościowo kodu, co najwyżej generuje kod który lepiej ogarnia się
> formalną weryfikacją a i to jest mocno naciągane.

Niezupełnie. W takich systemach może być wymaganie na pokrycie testami każdej
ścieżki. Jeżeli są wyjątki, to tych ścieżek nawet nie widać a rozstrzygnięcie
automatyczne ile ich jest i gdzie może wymagać dostępu do całego kodu i nawet wtedy
może być nierealne. Natomiast użycie iloczynu logicznego tak jak powyżej, chociaż
wątpliwe stylistycznie, jest jednak lokalne - tzn. analizę wszystkich ścieżek da się
zrobić w ramach tylko tego wyrażenia. Wtedy znacznie łatwiej spełnić wymaganie
pokrycia testami.
Dlatego nie zgadzam się z określeniem "wyszło jak zwykle". Ten przykład da się
obronić. Stylistycznie słaby (subiektywnie), ale broni się na poziomie procesu.

--
Maciej Sobczak * http://www.inspirel.com