On 09/06/2020 22:43, Maciej Sobczak wrote:
>> Programowania defensywnego na inpucie.
> Rzucam tezą, że ktoś z dobrą intencją ulepił koncept a cała masa ludzi ten koncept
powiela, już bez zastanowienia o co autorowi chodziło.
> Weź sobie funkcję std::sort. Ma trzy argumenty, trzeci to właśnie callback
komparatora (zwany w kręgach zbliżonych do akademickich "predykatem"). Otwórz sobie
header "algorithm" ze swojego kompilatora i poszukaj tam co robi funkcja std::sort ze
swoim trzecim argumentem (czyli "inputem", jak to nazywasz).
> Sprawdza, czy programista nie podał pustego wskaźnika/funktora/itp.?

Teraz weź dowolny nagłówek z Qt i poszukaj sobie Q_ASSERT. Niezłe
głupki, nie? Kto by traciła na to czas, Paaaanie...

> Tak więc biblioteka HTTP jest właśnie w takim towarzystwie (przynajmniej w tej
konkretnej kwestii...).

No ale to kiepskie towarzystwo. Co by o std:: nie mówić, jakościowo to
jest takie sobie, że nie wspomnę już że ma co najmniej kilka implementacji.

>>> Od kiedy to biblioteki HTTP służą do weryfikacji programów?
>> W każdym inpucie powinna być weryfikacja,
> To nie jest input, tylko część programu. Inputem jest URL z przeglądarki albo dane
z formatki w POST. I *to* należy walidować.

Więc mamy różne pojęcie o inpucie. Jako klient bibliteki widzę to
inaczej, nic nie poradzę.

>> ponieważ *ułatwia* to
>> debugowanie klientowi.
> Debugowanie ułatwia fakt, że gdybyś faktycznie spróbował zrobić taki błąd w tej
bibliotece, zamiast trollować na rympał, to byś zobaczył, że std::function rzuca
wtedy wyjątek, który biblioteka uczciwie wypisuje na podanym strumieniu do logowania
błędów.

Exceptions to nie asercje. Nie służa do tego samego. Narzekanie jest na
asercje a raczej ich brak. Asercje to rodzaj dokumentacji dla klienta.
Przydają się w debugu. Nic nie kosztują w runtime. Gdzie są wady które
powodują że nie warto?

> To programowanie defensywne, podobnie jak paranoja wokół unit testów, to niestety
efekt braku refleksji nad własnym warsztatem.

Paranoja wokół unit testów oznacza po drugiej stronie luzacki kod bez
śladu testowania. Rozsądek nakazuje być gdzieś w środku, specyfikacja
nakazuje czasem mieć prawie 100% pokrycia. Trudno tu doszukiwac się
refleksji, choć często muszę stopować młodych gniewnych którym wszystko
zawsze wychodzi dobrze od razu, tylko troche nie działa. Jednak pisanie
unit testów czasem się przydaje. Jak coś zapraszam do mnie, sam zobaczysz.

>>> Targetem są świadomi inżynierowie, którzy nie oczekują od biblioteki HTTP, że im
zrobi weryfikację poprawności programu...
>> Chyba takich jest relatywnie mało. Sądzepo ilości assertów w poważnych
>> biblitekach.
> No to ile assertów znalazłeś w std::sort na trzecim argumencie?

Trudno nazwać std:: poważną bibliteką pod kątem jakości. Obserwowałem
kiedyś rozwój stlport i muszę przyznać że podejście z gatunku "chyba
dobrze, komituj na produkcję" dało mi dużo do myślenia i zmianę własnego
warsztatu ze zwrotem przeciwnym.

> Ja sprawdziłem w bibliotekach standardowych z trzech różnych kompilatorów.

To sprawdź jeszcze resztę świata. Zacznij od Qt. Spodoba Ci się, tam
pracują sami nadprzyrodzeni hackerzy którzy mają reglamentowane asserty.
Ale i tak można ich tam troszkę znaleźć. Widocznie ktoś stwierdził że
czasem warto pilnować czy coś nie jest nullem, nawet jeśli klient tej
biblioteki jest nadprzyrodzonym superkoderem z kontraktem i +10 do
szczęścia.