Czy serwer powinien „być pobłażliwy” pod względem akceptacji i „odrzucać po cichu błędne dane wejściowe”?

27

Miałem wrażenie, że do tej pory wszyscy zgadzają się, że ta maksyma była błędem. Ale ostatnio widziałem tę odpowiedź, która ma „łagodny” komentarz, który był oceniany 137 razy (na dzień dzisiejszy).

Moim zdaniem pobłażliwość w akceptowaniu przeglądarek była bezpośrednią przyczyną totalnego bałaganu, jaki HTML i niektóre inne standardy sieciowe miały kilka lat temu, a dopiero niedawno zaczęły właściwie krystalizować się z tego bałaganu. Sposób, w jaki ja to widzę, łagodny w tym, co akceptujesz , doprowadzi do tego.

Druga część maksymy to „odrzuć wadliwe dane w trybie cichym, bez zwracania komunikatu o błędzie, chyba że jest to wymagane przez specyfikację” , a to wydaje się być obraźliwe. Każdy programista, który uderzył głową w ścianę, gdy coś się nie powiedzie, będzie wiedział, co mam na myśli.

Czy więc całkowicie się mylę? Czy mój program powinien być łagodny w tym, co akceptuje i cicho połykać błędy? Czy też źle interpretuję, co to znaczy?


Pierwotne pytanie brzmiało „program”, a ja o tym wszystkim myślę. Programy mogą być łagodne. Jednak tak naprawdę miałem na myśli interfejsy API: interfejsy udostępnione innym programom , a nie ludziom. HTTP jest przykładem. Protokół jest interfejsem używanym tylko przez inne programy. Ludzie nigdy nie podają bezpośrednio dat, które wpisują się w nagłówki, takie jak „Jeśli-zmodyfikowano-od”.

Pytanie zatem brzmi: czy serwer implementujący standard powinien być łagodny i dopuszczać daty w kilku innych formatach oprócz tego, który jest rzeczywiście wymagany przez standard? Uważam, że „łagodność” powinna odnosić się do tej sytuacji, a nie do ludzkich interfejsów.

Jeśli serwer jest łagodny, może się to wydawać ogólną poprawą, ale myślę, że w praktyce prowadzi to tylko do implementacji klienta, które ostatecznie polegają na łagodności i tym samym nie działają z innym serwerem, który jest łagodny w nieco inny sposób.

Czy serwer ujawniający niektóre interfejsy API powinien być łagodny, czy to bardzo zły pomysł?


Teraz na łagodną obsługę danych wprowadzanych przez użytkownika. Rozważ YouTrack (oprogramowanie do śledzenia błędów). Używa języka do wprowadzania tekstu, który przypomina Markdown. Tyle że jest „łagodny”. Na przykład pisanie

- foo
- bar
- baz

to nie udokumentowany sposób tworzenia listy punktowanej, a mimo to działało. W rezultacie zostało to często używane w naszym wewnętrznym narzędziu do wykrywania błędów. Pojawia się kolejna wersja, a ta łagodna funkcja zaczyna działać nieco inaczej, łamiąc garść list, które (źle) używały tej (nie) funkcji. Oczywiście udokumentowany sposób tworzenia list wypunktowanych nadal działa.

Czy moje oprogramowanie powinno być łagodne w zakresie akceptowanych danych wejściowych ?

Roman Starkov
źródło
4
Jeśli chodzi o „dyskretne odrzucanie błędnych danych wejściowych”, w każdym przypadku pytam, co należy uznać za błędne dane wejściowe. Jeśli zadajesz użytkownikowi pytanie i oczekujesz „tak” lub „nie”, czy „TAK” jest błędne? Co powiesz na „y”? Co powiesz na „oui”? Ogólnie rzecz biorąc, nie wstydź się mówić użytkownikowi, że jego wkład nie jest zgodny z oczekiwaniami. Jednak upewnij się, że byłeś jak najbardziej zaangażowany - moim zdaniem to właśnie oznacza „bądź łagodny”.
3
Jeśli mówisz o danych wejściowych użytkowników końcowych - które odnoszą się do linii znajomych aplikacji, powinieneś być wybitny; w przypadku danych wejściowych generowanych automatycznie (z API) powinieneś być szczegółowy (ścisły).
Burhan Khalid
2
W rzeczywistości łagodność HTML-a była powodem, dla którego stał się tak popularny (i surowość XHTML-u, dlaczego został on odrzucony).
Oliver Weiler
1
Wydaje mi się, że kluczem jest to, że jeśli jest to scenariusz, w którym możesz pozwolić, aby zakończyło się pełnym wdzięku niepowodzeniem, to przynajmniej rejestrujesz zdarzenie.
Przypon
2
@OliverWeiler Wydaje mi się, że niepowodzenie XHTML miało coś wspólnego z faktem, że był całkowicie niepotrzebny. HTML już tam był i trochę działał. Ponadto, chociaż HTML jest oczywiście niezwykle popularny, to trochę smutne, że nazywamy tę technologię sukcesem. Zaspokaja popyt, ale robi to tak samo dobrze, jak Symbian zaspokaja popyt na smartfony.
Roman Starkov,

Odpowiedzi:

9

Oczywiście masz całkowitą rację. Programy nigdy nie powinny być „łagodne”, ponieważ służą jedynie do maskowania problemów. Problemy należy podkreślać, a nie zamiatać pod dywan. Informacyjny komunikat o błędzie jest absolutną koniecznością, aby program był pomocny dla użytkownika.

Przez większość czasu, gdy podawane są niepoprawne / nieprawidłowe dane, dostawca tych danych (niezależnie od tego, czy jest to użytkownik, czy dane wyjściowe innego programu) prawdopodobnie nie wiedział, że są one nieprawidłowe. Połknięcie błędu sprawi, że będą przekonani, że jest (lub może być) ważny, co powoduje rozpowszechnianie nieprawidłowych danych.

Jedynym sposobem na współdziałanie systemów jest pełne i jednoznaczne zdefiniowanie tej współpracy. Program, który akceptuje dane spoza specyfikacji, de facto akceptuje te dane, nawet jeśli są one nieprawidłowe przez specyfikację, co nie tylko utrudnia zgodność, ale także oznacza, że ​​nie jest już formalnie zdefiniowane. Sam program jest teraz de facto standardem. Dlatego łagodnych programów nie można dalej rozwijać ani zastępować, ponieważ nie można wprowadzić najmniejszych zmian w sposobie ich działania.

Timwi
źródło
25

Myślę, że wszystko zależy od tego, kim jest twoja docelowa grupa demograficzna. Jeśli to programiści, to absolutnie nie. Twój program powinien zawieść mocno i wykrzyczeć krwawe morderstwo. Jednakże, jeśli twoi odbiorcy docelowi nie są programistami, twój program powinien być łagodny, gdzie może z gracją obsługiwać wyjątki, w przeciwnym razie szepcz słodkie krwawe morderstwo.

Jako studium przypadku weź odtwarzacz NPAPI Flash. Istnieje wersja „release” dla tych, którzy tak naprawdę nie dbają o 99% błędów, które mogą wystąpić, ale jest też wersja „debugująca”, która krzyczy krwawe morderstwo, gdy coś pójdzie nie tak. Każde wsparcie odtwarza treści Flash oczywiście, ale są kierowane na dwie zupełnie różne dane demograficzne.

Ostatecznie myślę, że ważne jest to: na czym troszczą się Twoi użytkownicy?

Demian Brecht
źródło
4
Zdecydowana większość narzędzi wiersza polecenia Unixy, które podają się za grupę docelową poza programistami, są jednak bezużyteczne dla użytkowników, którzy popełniają błędy. Nawet jeśli nie jesteś programistą, zwykle lepiej jest, aby program wyjaśnił problem, niż zrobić coś bezsensownego lub niezamierzonego.
Timwi
2
@romkyns: Nie do końca, mówię, że Twoja aplikacja powinna obsługiwać błędy w sposób, który ma sens dla docelowych użytkowników.
Demian Brecht
@Timwi: W takim przypadku narzędzia wiersza poleceń systemu Unixy są źle zaprojektowane;)
Demian Brecht
3
@romkyns - Myślę, że dobrym przykładem byłoby: W trybie debugowania program powinien zatrzymać wszelkie problemy i powiedzieć, co poszło nie tak. W trybie produkcyjnym chcesz, aby Twój program działał tak dobrze, jak to możliwe, i rejestruj wszelkie problemy, które może obsłużyć. W ten sposób programiści mogą zobaczyć, co zrobili źle i naprawić, ale użytkownikom nie będzie przeszkadzało to, czego nie mogą naprawić. Niektórych problemów oczywiście nie da się naprawić, ale dobrym przykładem są reguły stylu CSS, w których nadal można renderować witrynę, nawet jeśli nie rozumiesz jednej z reguł stylu.
Przywróć Monikę
1
Komentarz BrendanLonga trafia w sedno - czasami generowanie wyników jest ważniejsze niż poprawność. Niektóre błędy (lub ostrzeżenia) można z łatwością odzyskać bez wkładu użytkownika; to Ty decydujesz, co chcesz zrobić w takich przypadkach.
Daniel B
7

Istnieją dwa rodzaje „łagodnych”: Jednym z nich jest zaakceptowanie niepoprawnych danych wejściowych i próba ich zrozumienia, a drugim akceptacja różnych typów danych wejściowych.

Ogólnie rzecz biorąc, zawsze chcesz mieć drugi, gdy jest to wykonalne. Po pierwsze, umierasz szybko i ciężko. Przykład: daty.

Oto kilka przykładowych danych wejściowych, w tym poprawne, nieprawidłowe i niejednoznaczne.

  • 2011-01-02
  • 01/02/2011
  • Jan 2, 2011
  • 2-Jan-2011
  • Green

Jest tylko jeden nieważny wejścia tutaj: Green. Nawet nie próbuj zaakceptować tego jako daty. Ponieważ Greenoczywiście nie jest to data, jest to przypadek, w którym ciche wyciszenie jest dopuszczalne.

01/02/2011jest poprawny, ale niejednoznaczny. Niekoniecznie wiesz, czy została wprowadzona jako data amerykańska (2 stycznia), czy nie (1 lutego). Tutaj prawdopodobnie najlepiej jest zawieść głośno i poprosić użytkownika o jednoznaczną datę.

2011-01-02jest zwykle uważany za jednoznaczny, więc często dobrze jest założyć, że ma format „RRRR-MM-DD”, i kończy się niepowodzeniem. Jest to jednak trochę osąd w przypadku wprowadzania danych przez użytkownika.

Jan 2, 2011i 2-Jan-2011są ważne i jednoznaczne, należy je zaakceptować. Jednakże, The Second of January of the year 2011jest również ważne i jednoznaczne, ale dzieje się tak daleko w trosce o leniency jest przesadą. Idź naprzód i po cichu zawiedź Green.

Krótko mówiąc , odpowiedź brzmi „to zależy”. Sprawdź, co można wprowadzić, i upewnij się, że nigdy nie akceptujesz sprzecznych typów danych wejściowych (takich jak DD/MM/YYYYvs MM/DD/YYYY).

W kontekście powiązanego pytania / komentarza jest to przypadek 2011-01-02. Dane wejściowe wyglądają jak JSON i sprawdzają poprawność jak JSON, nawet jeśli typ mimetyczny jest nieprawidłowy; śmiało i spróbuj użyć go, nawet jeśli zawiedzie w pewnym momencie niżej.

Izkata
źródło
1
Jest jedna rzecz, której tutaj nie rozważasz. Jeśli użytkownik wpisze ten ciąg, to tak, powinienem zaakceptować różne formaty, co do tego nie ma wątpliwości. Ale mówimy o interfejsach API. Klientami interfejsów API są inne programy. Jeśli jest łagodny w swoim formacie daty, każdy przyszły serwer udostępniający ten interfejs API będzie musiał być łagodny w ten sam sposób lub ryzykować niezgodność. Łagodność kończy się raczej szkodą niż pomocą, nie sądzisz?
Roman Starkov
1
@romkyns Myślę, że nie rozumiesz, gdzie leży łagodność. API powinien być łagodny, co to akceptuje (powinien zrozumieć wszystko 2011-01-02, Jan 2, 2011i 2-Jan-2011, jeśli to nie jest zbyt trudne do wykonania), a nie w to, co wyprowadza . Przyszli klienci tego interfejsu API nawet nie muszą wiedzieć o żadnym z nich, o ile poprawnie wprowadzają jeden z nich. Najlepiej byłoby, gdyby warstwa API przekształciła je wszystkie w tę samą wewnętrzną reprezentację, z której korzysta kod przed przekazaniem go dalej.
Izkata,
@romkyns Dane wyjściowe mogą na przykład zawsze mieć 2011-01-02format, i to ten, który należy umieścić w dokumentacji. Nie widzę żadnego szkodliwego efektu.
Izkata,
4
@Izkata: Źle zrozumiałeś. Wyobraź sobie, że istnieje stary program, który jest dostępny tylko jako plik binarny. Musisz napisać nowy program, który akceptuje te same dane wejściowe co stary. Jeśli stary program był dobrze zdefiniowany w tym, co akceptuje, twoje zadanie jest dobrze zdefiniowane. Jeśli jest łagodny, to twoja praca jest niemożliwa.
Timwi
1
Zdecydowanie się nie zgadzam. chyba że jest to wejście wprowadzone przez użytkownika, zawsze należy ściśle przestrzegać zarówno wejścia, jak i wyjścia. Co się stanie, gdy twoja usługa będzie wymagała ponownego wdrożenia? Czy udokumentowałeś wszystkie możliwe formaty dat? Musisz wdrożyć je wszystkie, ponieważ nie chcesz, aby starzy klienci się załamali. Proszę stosować ISO 8601 dla wszystkich wygenerowanych maszynowo instancji i okresów dat: jest dobrze określony i szeroko dostępny w bibliotekach. Nawiasem mówiąc, co naprawdę oznacza 2011-01-02? Przedział czasu od 00:00 2 do 00:00 3? W jakiej strefie czasowej?
Dibbeke,
6

Cicha porażka jest najgorszą rzeczą, jaką możesz zrobić. Czy próbowałeś debugować interfejs API z cichą awarią? To niemożliwe .

Jest tam napis „Zrób wszystko, aby odzyskać, ale wyślij szczegółowy błąd” i „Cicha awaria”.

DeadMG
źródło
3

Wydaje mi się, że Prawo Postela - „Bądź konserwatywny w tym, co robisz, bądź liberalny w tym, co akceptujesz od innych” - jest przedmiotem dyskusji na temat usługi JSON. Zwykle dotyczy to usług internetowych, a nie interfejsu użytkownika.

W przypadku konstruktywnej informacji zwrotnej od użytkownika i ograniczania wkładu użytkownika stosujemy zasadę.

MarcLawrence
źródło
Ale jeśli spojrzysz na odpowiedzi tutaj, wydaje się, że wszyscy zgadzają się, że ma to zawsze sens tylko dla interfejsów użytkownika, tj. Odwrotnie niż w pierwotnym prawie.
Roman Starkov,
Rozumiem twoje zdanie i zgadzam się z plakatami, że celem jest czysty ścisły interfejs API / usługa, ale na lepsze lub gorsze wiem, że dodałem „solidność” w takiej czy innej formie do moich usług. Zwykle tłumaczenie wartości lub dwa na granicy. Dopóki znaczenie jest jasne, aplikacja wie, jak przetworzyć wiadomość i nie są naruszane żadne reguły biznesowe, a następnie dodanie niezawodności pomoże interoperacyjności.
MarcLawrence
Dopóki ktoś inny nie wprowadzi i nie wdroży twojej specyfikacji, tylko po to, by przekonać się, że „niezawodność”, na której polegają setki klientów, nie była w rzeczywistości zgodna ze specyfikacją i musi zostać poddana inżynierii wstecznej ...
Roman Starkov
3

Myślę, że jest to dobrze omówione w rozdziale 1, sekcji 6 TAOUP. W szczególności reguła naprawy , która mówi, że program powinien robić to, co może z wejściem, przekazywać poprawne dane do przodu, a jeśli poprawna odpowiedź nie powiedzie się, zrób to jak najszybciej.

Podobną koncepcją jest programowanie obronne . Ty nie wiesz, jakiego rodzaju wejścia otrzymasz, ale program powinien być wystarczająco wytrzymałe, aby objąć wszystkie przypadki. Oznacza to, że należy zaprogramować w przypadkach odzyskiwania znanych problemów, takich jak zniekształcone dane wejściowe, i przechwytywać wszystkie przypadki, aby obsłużyć nieznane.

Więc dyskretne odrzucanie wadliwych danych wejściowych jest w porządku, o ile sobie z nimi radzisz. Nigdy nie powinieneś po prostu upuszczać go na podłogę.


W przypadku API myślę, że pobłażliwość jest taka sama jak w przypadku programu. Dane wejściowe są nadal niepoprawne , ale próbujesz naprawić jak najwięcej. Różnica polega na tym, co uważa się za prawidłową naprawę . Jak zauważyłeś, łagodny interfejs API może powodować problemy, ponieważ ludzie używają „funkcji”, które nie istnieją.

Oczywiście API jest tylko wersją niższej wersji reguły składu . Jako taki, jest naprawdę objęty zasadą najmniejszego zaskoczenia , ponieważ jest interfejsem.

Jak zauważa cytat ze Spencera, unikaj powierzchownego podobieństwa, które można argumentować na temat „rozmytych” danych wejściowych. W tych warunkach zwykle twierdzę, że wszystko wskazuje na niemożność naprawy programu, ponieważ nie będzie wiedział, co jest pożądane, i jest to najmniej zaskakujące dla bazy użytkowników.

Masz jednak do czynienia z datami, które mają wiele „standardów”. Czasami nawet mieszają się w jednym programie (łańcuch). Ponieważ wiesz, że data jest oczekiwana, próba rozpoznania daty jest po prostu dobrym projektem. Zwłaszcza jeśli data pochodzi z jakiegoś programu zewnętrznego i jest przekazywana niezmodyfikowana przez sekundę w drodze do ciebie.

Spencer Rathbun
źródło
2

Programy wdrażane na serwerze przez większość czasu powinny przyjmować tysiące żądań co minutę, a czasem co sekundę. Jeśli program serwera zaakceptuje i poprawi błędne dane wejściowe od klientów, obawiam się, że będą miały 2 wady:

  1. Utrata cennego czasu serwera. Przy ponad 1000 żądań na sekundę sprawdzanie błędów w każdym żądaniu może odzwierciedlać powolną odpowiedź dla każdego klienta.
  2. Nieuczciwe wobec klienta / programów klienckich, które zapewniają prawidłowe dane wejściowe. Poza tym, gdy programista po stronie serwera siedzi na kodzie serwera, musi pomyśleć o różnych przypadkach, jakie mogą być nieprawidłowe dane wejściowe. Kto to zadecyduje?

Programy serwera nie powinny przyjmować błędnych danych wejściowych, ale serwery powinny zwracać klientowi komunikat o błędzie, jeśli dane wejściowe są błędne.

Abhishek Oza
źródło
2

Idealnie, pod względem koncepcyjnym, jest robienie tego, co można zrobić bezpiecznie, przy jednoczesnym zapewnieniu, że ktoś, kto może naprawić jakiekolwiek problemy, zostanie w jakiś sposób powiadomiony o nich. W praktyce, oczywiście, ostatnie ograniczenie jest często niemożliwe do spełnienia bezpośrednio, dlatego pytanie staje się najlepsze w przypadku podejrzanych danych wejściowych.

Jedną z rzeczy, która może być bardzo pomocna w projektowaniu protokołu, specyfikacji formatowania lub „języka”, jest możliwość rozróżnienia czterech kategorii potencjalnych niezrozumiałych elementów:

  1. Rzeczy, które należy odfiltrować, jeśli nie są zrozumiane.
  2. Rzeczy, które powinny zostać zignorowane, jeśli nie zrozumiane, ale mimo to zachowane, jeśli dane muszą zostać przekazane (być może w jakimś opakowaniu, aby wskazać, że przeszedł przez co najmniej jeden etap, który go nie zrozumiał)
  3. Rzeczy, które powinny wygenerować ostrzeżenie, jeśli nie są zrozumiane, ale nie powinny uniemożliwiać próby odzyskania danych (np. Na stronie internetowej, obiekt, którego typ jest nieznany, ale którego koniec w pliku jest dobrze zdefiniowany, może być renderowany jako czerwony „X” bez uniemożliwienia renderowania reszty strony).
  4. Rzeczy, które wskazywałyby na to, że wszystko, co ich nie rozumie, może mieć poważne i niemożliwe do naprawienia problemy w innym miejscu (np. Wskaźnik, że pozostałe dane są kompresowane i które są zrozumiałe dla wszystkiego, co mogłoby wykonać wymaganą dekompresję).

Posiadanie dobrze zdefiniowanej konwencji, według której aplikacje potrafiące odczytać dowolną wersję formatu danych będą mogły rozpoznać, która kategoria jest odpowiednia dla wszystkiego, co jest generowane zgodnie z późniejszymi wersjami, jest znacznie lepszym podejściem niż próba zastosowania środków zgodności ad-hoc później. Na przykład, jeśli format pliku ma wiersze w postaci „Tag: Value”, można określić, że pierwszy znak dowolnego tagu wskaże kategorię, do której należy; w przypadku znaczników kategorii cichego ignorowania pierwszy znak może również wskazywać wersję standardu, dla którego znacznik ma być poprawny (tak, że jeśli znacznik „ciche ignorowanie” twierdzi, że jest obecny w wersji 3 standard, parser dla wersji po cichu go zignoruje, ale parser dla wersji 3 lub nowszej skurczyłby się, gdyby nie mógł go przeanalizować).

Najważniejsze w każdym przypadku jest uniknięcie przekształcania niejednoznacznych lub źle zrozumianych danych w błędne dane. W niektórych przypadkach lepszym rozwiązaniem może być w ogóle odmowa propagowania niejednoznacznych danych, ale w innych przypadkach lepsza może być propagacja dokładnie w takiej postaci, w jakiej je otrzymano, na wypadek gdyby odbiorca uznałby je za jednoznaczne. To, co naprawdę niebezpieczne, jeśli wręcz nie zło, to konwersja danych przy użyciu różnych założeń, np. Konwersja listy dat, takich jak:

01.12.12
13.12.12
99/12/12

na listę dat takich jak

2012-01-12
13.12.2012
1999-12-12

Nawet jeśli ktoś miał listę z kilkoma błędnie wprowadzonymi datami, człowiek może mieć listę w oryginalnym formacie, aby ustalić, który format jest poprawny, i oznaczyć wątpliwe wartości do dalszych badań (porównanie z innymi rekordami itp. ) Renderowanie dat w tym ostatnim formacie byłoby jednak beznadziejne i nieodwracalne.

supercat
źródło
Dobrze powiedziane. Podoba mi się, jak twoja odpowiedź jest głębsza. Kusi mnie, by to zaakceptować, ale biorąc pod uwagę ogólne zainteresowanie tym pytaniem, myślę, że zostawię to na jakiś czas.
Roman Starkov,
1

Moje wrażenia z interfejsu użytkownika pochodzą głównie z systemów stacjonarnych. Strony internetowe są różne, chociaż widziałem kilka witryn, które mogą stanowić wyzwanie dla systemu komputerowego. Ale za co warto:

Odkryłem, że komunikaty o błędach powinny być ostatecznością; idealny system w ogóle ich nie miałby. Najlepiej jest przede wszystkim nie dopuścić do złych wpisów: użytkownik nie może wpisać „zielony”, jeśli wybiera z rozwijanej listy miesięcy. Nie może nacisnąć szarego przycisku.

Następną najlepszą rzeczą jest zaakceptowanie złych danych. Załóżmy, że wyświetlasz histogram dziennej sprzedaży za miesiąc. Po wprowadzeniu przez użytkownika wykres obejmuje wiek, a słupek na wiek jest 10 razy wyższy niż pozostałe. Użytkownik wie teraz, że zrobił coś złego, a ponadto wie dużo więcej o tym, co zrobił źle, niż jakakolwiek wiadomość mogłaby mu powiedzieć. Gdy wpis jest graficzny - na przykład poprzez przeciągnięcie myszą - tego rodzaju opinie nadal działają i są nieocenione. Kilka danych wejściowych może być niepoprawnych, ale przy użyciu tej metody użytkownik otrzymuje natychmiastową, szczegółową informację zwrotną na temat wyników każdej pozycji myszy.

To powiedziawszy, czasami użytkownik musi wiedzieć, dlaczego przycisk jest wyszarzony, aby nie mógł go nacisnąć. Wtedy nie ma na to rady (jeśli nie jest , daj mi znać), ale do ungray przycisk, a kiedy kliknie na nim, dać mu dobre wyjaśnienie dlaczego przycisk nie działa w tej chwili.

RalphChapin
źródło
0

Oświadczenie dotyczy wysyłania informacji przez Internet. Jedną z rzeczy związanych z wysyłaniem informacji przez Internet jest to, że nie zawsze dociera ona do celu w ogóle lub jest fragmentaryczna.

Pieter B.
źródło
0

Coś, co wydaje się tutaj pominięte - jakie są konsekwencje niepowodzenia?

Wyświetlić stronę internetową? Powinieneś zrobić wszystko, aby tolerować złe dane wejściowe. Masz do wyboru, co możesz wyświetlić lub zgłosić błąd. Ten ostatni kurs nie daje użytkownikowi nic, a zatem powinien być jedynie ostatecznością, ponieważ daje użytkownikowi całkowicie bezużyteczny wynik, byłoby ciężko, aby błąd był gorszy niż ten.

Z drugiej strony, jeśli prosi o cel Minutemana III, odrzucasz „Moskwę” jako dane wejściowe, ponieważ jest to potencjalnie niejednoznaczne.

Loren Pechtel
źródło
Więc nawet jeśli jesteś programistą i napisałeś jakiś głupi kod, system powinien iść naprzód i zrobić wszystko, aby coś pokazać, zamiast po prostu zatrzymać się i wykrzyczeć „och, spieprzyłeś tutaj (numer wiersza)”? Nie sądzisz, że właśnie to prowadzi do niewiarygodnie złego kodu?
Roman Starkov,
@romkyns: Masz tryby debugowania dla tego rodzaju rzeczy, które są surowe w skrzeczeniu o błędach.
Loren Pechtel