🚀 go-pugleaf

> > 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