Maciej Sobczak <s...@g...com> wrote:

>> > To następna obserwacja: jeśl wpływa to na runtime release należy to
>> > odrzucić. Wszelakie checkery asercyjne, za wyjątkiem programowania
>> > defensywanego, nie mogą istnieć w kodzie produkcyjnym.
>>
>> Nigdy nie rozumiałem sensu tego rozumowania
>
> Sens jest również taki, że (jak na ironię!) w systemach krytycznych nie
> da się spełnić kryterium 100% pokrycia kodu testami czegoś, co ma
> asserta. Tzn. jeśli w kodzie jest assert, który *z założenia* ma się
> nigdy nie wykonać, to jest to tzw. dead code i ma go nie być. Bo jeśli
> jest, to nie da się go przetestować. Albo inaczej: nie da się wykazać
> testami, że coś się nigdy nie wykona, więc nie da się zdobyć w ten
> sposób pewności, że się nie wykona. A jeśli osiągniemy tą pewność innymi
> metodami (np. formalnymi), to asserta dynamicznego może wtedy w ogóle
> nie być.

To prawda. Ja (na szczęście -- bo odpowiedzialność jest ogromna) nigdy nie
pisałem systemów krytycznych, ani nigdy u SQA nie robiło u nas tego typu
testów (choć oczywiście to, co mówisz, ma sens).

> Zupełnie niezależnie od tego, w pewnych środowiskach walnięcie assertem
> jest bez sensu, bo i tak nie ma do kogo przekazać sterowania. Assert w
> rozruszniku serca jest bez sensu, nie tylko technicznie, ale też
> filozoficznie.

To znów bardzo specyficzne zastosowanie i podejrzewam, że programowanie
rozrusznika serca rządzi się swoimi regułami (raz, że jest to typowy układ
embedded bez możliwości wyrzucenia błędu -- bo jak, w pulsie pacjenta
zakodować linię kodu? -- a dwa, że jest to system krytyczny, w którym
nieprawidłowa praca programu może powodować chorobę lub śmierć).
Podejrzewam że pisząc oprogramowanie na rozruszniki serca stosuje się
jakąś formę MISRA lub odpowiednik i że są tam jakieś sprzętowe failsafe'y,
które uniemożliwiają przejście programowi w stan, który będzie zagrażał
życiu lub zdrowiu. Tak to sobie przynajmniej wyobrażam.

Z drugiej strony spotkałem się z systemem ładowania baterii (Li-Po), w
którym zamiast dedykowanego kontrolera wyłączanie ładowarki było robione
software'owo. Wszystko działało... do momentu, aż w systemie pojawił się
błąd i zasilanie baterii nie było wyłączane po zakończeniu (nie wiem też
co by było, gdyby urządzenie się zawiesiło).

> To nie jest tylko kwestia szybkości działania, to może być też kwestia
> sensowności istnienia samego asserta.

Tak... czasem nie ma możliwości zaraportowania błędu i jest pytanie typu
"ok, pojawił się błąd, ale co teraz?". Tylko właśnie -- co wtedy? Jeśli
mogę sobie na to pozwolić i na danej platformie ma to sens, to staram się
to w jakiś sposób zaraportować. Jeśli sensu ani możliwości nie ma, to
pozostaje przestawienie wyjść w niegroźny stan i kontrolowany restart...
i jeśli błąd nadal występuje, to tak w nieskończoność.

Tak czy inaczej, jeśli system umożliwia jakieś zaraportowanie błędu lub ma
możliwość interakcji z użytkownikiem, to używam tego. Zdarzało się, że
tego typu asserty wyskakiwały na produkcji (choć teoretycznie kod był
przetestowany przez SQA i teoretycznie nie powinny wyskoczyć). Dużo
bardziej wolę dostać raport o błędzie wraz z tym, co wypluł program i co
pozwala mi zdiagnozować błąd, niż pozwolić programowi działać dalej w
stanie, w którym nie powinien się znaleźć. Nawet jeśli nie ma możliwości
zaraportowania, to dużo bardziej wolę, jak program się zatrzymuje, a błąd
jest jawny, niż jak błąd jest ukrywany i po jakimś czasie coś działa, ale
nie tak jak powinno.

Oczywiście nie pisząc oprogramowania na rozruszniki itd. systemy mogę
sobie na to pozwolić -- awaria programu nie ma w tym przypadku skutków
zdrowotnych (choć może mieć finansowe wynikające z braku możliwości
używania programu).

--
https://www.youtube.com/watch?v=9lSzL1DqQn0