Jakie są problemy dewelopera z pomocnymi komunikatami o błędach? [Zamknięte]

To nadal zdumiewa mnie, że w dzisiejszych czasach, produkty które mają latach użytkowania na swoim koncie, zbudowany przez zespoły specjalistów, jeszcze do tej pory - nie zapewniają pomocne komunikaty o błędach dla użytkownika. W niektórych przypadkach dodanie tylko odrobiny dodatkowych informacji może zaoszczędzić użytkownikowi godzin kłopotów.

Program, który generuje błąd, wygenerował go z określonego powodu. Ma wszystko do dyspozycji, aby w jak największym stopniu poinformować użytkownika, dlaczego coś się nie udało. A jednak wydaje się, że udzielanie informacji pomagających użytkownikowi ma niski priorytet. Myślę, że to ogromna porażka.

Jeden przykład pochodzi z SQL Server. Gdy próbujesz przywrócić używaną bazę danych, całkiem słusznie na to nie pozwala. SQL Server wie, jakie procesy i aplikacje uzyskują do niego dostęp. Dlaczego nie może zawierać informacji o procesach korzystających z bazy danych? Wiem, że nie każdy przekazuje Applicatio_Nameatrybut w ciągu połączenia, ale nawet wskazówka na temat danego komputera może być pomocna.

Kolejnym kandydatem, także SQL Server (i mySQL) jest piękny string or binary data would be truncatedkomunikat o błędzie i jego odpowiedniki. Często zdarza się, że przeglądana jest prosta instrukcja SQL, a tabela pokazuje winowajcę. Nie zawsze tak jest, a jeśli silnik bazy danych wykrył błąd, dlaczego nie może nam to zaoszczędzić tego czasu i po prostu mówi nam, która to cholerna kolumna? W tym przykładzie można argumentować, że sprawdzenie wydajności może mieć negatywny wpływ na wydajność, co utrudniłoby pisarzowi. Dobrze, kupię to. Co powiesz na to, że gdy silnik bazy danych wykryje błąd, dokonuje szybkiego szybkiego porównania między wartościami, które miały być przechowywane, a długością kolumn. Następnie wyświetl to użytkownikowi.

Okropne Adaptery tabel ASP.NET są również winne. Zapytania mogą być wykonywane i można otrzymać komunikat o błędzie informujący, że gdzieś naruszane jest ograniczenie. Dziękuję za to. Czas porównać mój model danych z bazą danych, ponieważ programiści są zbyt leniwi, aby podać nawet numer wiersza lub przykładowe dane. (Dla przypomnienia, nigdy nie użyłbym tej metody dostępu do danych z wyboru , to tylko projekt, który odziedziczyłem!).

Ilekroć zgłaszam wyjątek od mojego kodu C # lub C ++, przekazuję użytkownikowi wszystko, co mam pod ręką. Podjęto decyzję o jej przekazaniu, więc im więcej informacji dam, tym lepiej. Dlaczego moja funkcja zgłosiła wyjątek? Co zostało przekazane i czego oczekiwano? Trochę dłużej zajmuje mi umieszczenie czegoś znaczącego w treści komunikatu o wyjątku. Do diabła, nie pomaga mi tylko podczas rozwoju, ponieważ wiem, że mój kod rzuca rzeczy, które są znaczące.

Można argumentować, że skomplikowane komunikaty o wyjątkach nie powinny być wyświetlane użytkownikowi. Chociaż nie zgadzam się z tym, jest to argument, który można łatwo uspokoić, mając inny poziom gadatliwości w zależności od wersji. Nawet wtedy użytkownicy ASP.NET i SQL Server nie są typowymi użytkownikami i wolą coś pełnego gadatliwości i pysznych informacji, ponieważ mogą szybciej wyśledzić swoje problemy.

Dlaczego programiści uważają, że w dzisiejszych czasach dobrze jest podawać minimalną ilość informacji w przypadku wystąpienia błędu?

To 2011 chłopaki, chodź na .

Chociaż istnieje wiele przykładów złych komunikatów o błędach, których po prostu nie powinno być, musisz pamiętać, że nie zawsze można podać informacje, które chcesz zobaczyć.

Istnieje również obawa przed ujawnieniem zbyt dużej ilości informacji, co może prowadzić do błędów programistów po stronie ostrożności. (Obiecuję ci, że gra słów nie była zamierzona, ale nie usuwam jej teraz, gdy ją zauważyłem).

Czasami zdarza się również, że złożony komunikat o błędzie jest bezużyteczny dla użytkownika końcowego. Siding z przeciążeniem informacyjnymi niekoniecznie jest dobrym podejściem do komunikatów o błędach. (Można to najlepiej zapisać do logowania.)

Programiści nie są odpowiednimi osobami do pisania komunikatów o błędach.

Widzą aplikację pod niewłaściwym kątem. Są bardzo świadomi tego, co poszło nie tak w kodzie, ale często nie podchodzą do oprogramowania z punktu widzenia próby osiągnięcia czegoś. W rezultacie to, co jest ważne dla dewelopera, niekoniecznie musi być ważne dla użytkownika.

Widok charytatywny:

• Deweloper ściśle współpracował z kodem i starał się zrozumieć kogoś, kto nie rozumiał, jak go obsługiwać. W rezultacie uważają, że komunikaty o błędach są w porządku, po prostu nie mają dobrych ram odniesienia, dzięki którym mogliby je ocenić.

• Inteligentne komunikaty o błędach są w rzeczywistości trudne. Nie tylko je piszesz, ale musisz dowiedzieć się wszystkiego, co może pójść nie tak, ocenić prawdopodobieństwo i dostarczyć użytecznych informacji (które prawie na pewno różnią się w zależności od kontekstu) z powrotem do osoby czytającej wiadomość, aby umożliwić jej naprawienie.

• W przypadku większości aplikacji trudno jest znaleźć odpowiedni czas na zrobienie czegoś takiego, a następny programista naprawdę by tego chciał, ponieważ błędy nie występują tak często. Poza tym, jeśli miałeś ten dodatkowy czas, nie powinieneś go spędzać na zatrzymywaniu błędów, zamiast na zgłaszaniu ich?

Niecodzienny widok:

• Komunikaty o błędach i obsługa błędów są nudne, jest o wiele więcej interesujących rzeczy do pracy, a mój szef jest na moich plecach w sprawie kolejnej rzeczy. Rozumiem ten kod, wszystko będzie dobrze, następny facet w końcu go dopracuje i do tej pory mnie nie będzie, więc to nie mój problem.

Rzeczywistość jest prawdopodobnie gdzieś pośrodku, choć moje doświadczenie mówi mi, że jest to znacznie więcej niż pierwsze - w zasadzie jest to dość trudne i wymaga sporo wysiłku, aby poradzić sobie z czymś, co prawdopodobnie nie nastąpi.

Niestety, bardziej pomocne komunikaty o błędach kosztują czas programisty, co równa się pieniądze firmy. Produkty są wystarczająco drogie, aby zbudować takie, jakie są. Tak, byłoby wspaniale mieć bardziej pomocne komunikaty o błędach i zgadzam się, że powinny być zawarte bardziej przydatne. Jednak faktem jest, że kiedy masz mało czasu, a pieniądze są na linii, musisz coś wyciąć. Najpierw pojawią się „ładniejsze komunikaty o błędach”, jakie mogą zobaczyć menedżerowie.

Zgadzam się, że komunikaty o błędach powinny być jak najbardziej szczegółowe.

Jednym z powodów ogólnych komunikatów o błędach jest prawdopodobnie użycie kodów błędów. Korzystając z wyjątków, możesz przekazać wszystko, czego potrzebujesz w komunikacie o błędzie. Używając kodów powrotu, nie ma miejsca na zakodowanie nazwy kolumny. Być może błąd jest obsługiwany przez funkcję ogólną, która nie zna kontekstu i po prostu tłumaczy kod błędu na ciąg znaków.

• Czasami zbyt wiele informacji może stanowić zagrożenie bezpieczeństwa; nie wiesz, kto czyta komunikat o błędzie
• Czasami operacja, która zwróciła wyjątek, jest tak złożona, że ​​niemożliwe jest uzyskanie znaczącego komunikatu bez negatywnego wpływu na szybkość / złożoność kodu

Jako ogólną uwagę należy wziąć pod uwagę, że każdy błąd lub wyjątkowa sytuacja jest - właśnie to: wyjątkowa. Przecina zaplanowaną i zaprojektowaną procedurę. Jest to niezgodne ze sposobem, w jaki planowano działać. Gdyby tak nie było, nie byłoby potrzeby ratowania się z powodu przerwania błędu.

My, programiści, jesteśmy szkoleni, aby dbać o samoobronę tej planowanej procedury. W związku z tym rutynowo włączamy niektóre kontrole poczytalności w celu weryfikacji naszych założeń. Kiedy te testy poczytalności zawiodą, po prostu wiemy, że plan jakoś się nie udał ...

Twoje żądanie - z punktu widzenia użytkownika może wyglądać na zdrowy rozsądek - jest niemożliwe do spełnienia, jeśli weźmiesz pod uwagę rzeczywistość działania takiego systemu. Poprosisz o uporządkowane oświadczenie z dobrze zorganizowanymi i odpowiednimi informacjami. Co więcej, prosisz nawet, aby ta prezentacja odbyła się w sposób, który pasuje do ogólnego projektu aplikacji / obsługi. Oczywiście ta informacja istnieje gdzieś w systemie. Oczywiście istnieje nawet w uporządkowany i dobrze zorganizowany sposób (miejmy nadzieję). ALE w momencie wystąpienia błędu nikt nigdy nie planował udostępnienia tych informacji. Błąd zawsze oznacza częściową utratę kontroli.Ta utrata kontroli może wystąpić na różnych poziomach. Może to oznaczać, że system zachowuje się w czasie wykonywania inaczej niż planowano. Ale może się również zdarzyć, że faktyczne wdrożenie okazało się znacznie trudniejsze i różniło się szczegółami, niż planowano, i nie istniało żadne ustalone postanowienie, aby poradzić sobie z tą sytuacją w sposób zadowalający. To także jest częściowa utrata kontroli.

Odnosząc to do konkretnego przykładu, który podałeś: Jeśli w punkcie błędu znana byłaby nazwa i typ kolumny tabeli, a ponadto długość wymaganej przestrzeni, to nie byłoby żadnego powodu zgłaszanie błędu, prawda? Możemy po prostu naprawić sytuację i postępować zgodnie z planem. Sam fakt, że jesteśmy zmuszeni zgłosić błąd, pokazuje nam, że sprawy poszły na manowce. Sam fakt, że te informacje nie są dostępne, jest wyjątkiem .

To, co piszę tutaj, może wydawać się oczywiste i po prostu zdrowy rozsądek. Ale w rzeczywistości jest to niezwykle trudne do zrozumienia. Nieustannie staramy się to zrozumieć, stosując kategorie moralne - tak jak musi być sprawca, musi być zła leniwa osoba, która nie dba o biednego użytkownika, muszą być chciwi biznesmeni, którzy wybrali tanią kalkulację. Wszystko to jest zupełnie poza celem

Możliwość utraty kontroli wynika z faktu, że robimy rzeczy w zaplanowany i uporządkowany sposób .

Pracuję jako inżynier wsparcia dla firmy programistycznej i często widzimy nowe komunikaty o błędach. Często, gdy odsyłam je z powrotem do naszego zespołu programistów, muszą oni szukać wiadomości w źródle aplikacji.

Wydaje mi się, że nawet gdyby nie zostało ono przedstawione użytkownikom, zaoszczędziłoby nam dużo czasu, gdyby zespół deweloperów dodał notatkę do dokumentu indeksu komunikatów o błędach lub bazy danych za każdym razem, gdy dodaliby nową. zdecydowanie szybciej znajdujemy przyczynę problemów klientów i oszczędzamy im czas ...

Problem, który tam widzisz, jest w rzeczywistości jednym z efektów ubocznych właściwego kapsułkowania i ukrywania informacji.

Nowoczesne systemy są niezwykle skomplikowane. Jest małe prawdopodobieństwo, że przeciętny programista jest w stanie utrzymać w głowie mentalny model całego systemu, od interfejsu użytkownika po surowy plik binarny, podczas gdy on koduje jakieś konkretne zadanie.

Tak więc, gdy programista siedzi i koduje, powiedzmy, kawałek, który przywraca plik bazy danych, jego model mentalny jest całkowicie wypełniony bitami otaczającymi akt przywracania pliku bazy danych. Musi (i zgaduję, że nie napisałem tego kodu) odczytać plik, sprawdzić właściwości, odczytać wersje, wykonać kopię zapasową istniejących danych, wybrać strategię scalania / nadpisywania itp. Całkiem prawdopodobne, że nawet przejście biorąc pod uwagę interfejs użytkownika, znajduje się w ciągu błędu zapisanym w module obsługi wyjątków. Coś jak:

catch (IOException error)
{
//File is in use
throw new GenericExceptionParsedByTheUIThread("File is in use.");
}

W tym przykładzie przydatne informacje, o które pytasz w kontekście procesów, które mogą wykorzystywać plik, a nawet inne wątki w bazie danych, są całkowicie poza zakresem (programowo). Mogą istnieć setki klas, które zajmują się plikami DB; importowanie do tych klas informacji o każdym innym procesie korzystającym z plików lub funkcjonalność w celu uzyskania dostępu do systemu plików i sprawdzenia innych uruchomionych procesów (zakładając, że procesy te znajdują się nawet na TYM komputerze) spowodowałyby tak zwaną nieszczelną abstrakcję ; wydajność wiąże się z bezpośrednim kosztem.

W ten sposób tego rodzaju błędy mogą się utrzymywać we współczesnych czasach. Oczywiście wszystkie MOGĄ zostać naprawione; ale w wielu przypadkach wiąże się to z dużo większym nakładem pracy, niż mogłoby się wydawać (w tym przypadku może być konieczne przejście tej funkcji do wyliczania połączeń sieciowych i udziałów w celu sprawdzenia, czy komputer zdalny używa tego pliku bazy danych dla niektórych powód), a koszt nie jest trywialny.

Moim ulubionym był (pod koniec lat 70.) kompilator Univac Fortran IV, gdy czytałem cyfry, wiernie ogłoszono

Podjęto próbę interpretacji danych pozbawionych znaczenia

Wierzę, że większość komunikatów o błędach to tak naprawdę zorientowane na programistę (siebie) glorified instrukcje debugowania kodu / printf.

Pisanie zorientowanych na użytkownika komunikatów o błędach oznacza wiedzieć, kim jest użytkownik i przewidywać, co będzie chciał wiedzieć. Będąc w trakcie pisania kodu, programista jest bardziej skłonny napisać przydatny dla siebie komunikat o błędzie, zarówno w celu debugowania pisanego przez siebie kodu, jak i przydatny w znanych lub dominujących przypadkach użycia.

Przejście od pisania kodu do projektowania tekstowej części interfejsu użytkownika (lub doświadczenia użytkownika) to zmiana kontekstu. W dużych aplikacjach, takich jak aplikacje wielojęzyczne, które mogą oznaczać, że są przekazywane innej osobie lub zespołowi (interfejs użytkownika, tłumaczenie), a nie całkowicie obsługiwane przez programistę, więc jeśli programista nie wyjaśni dokładnie kontekstu wiadomości, ważne szczegóły mogą być łatwo zgubić.

Oczywiście sprawdzanie i weryfikowanie obsługi błędów jest często uważane za niski priorytet, o ile tylko błędy i wyjątki są obsługiwane (tzn. Wychwytywane), nie przywiązuje się do nich dużej wagi. Jest to psychicznie nieocenione miejsce w bazie kodu dla programistów lub QA do oceny, ponieważ warunki błędu często mają negatywną konotację (tj. Błąd lub awarię) z nimi związane.

Myślę, że powodem jest to, że raportowanie / obsługa błędów odbywa się zawsze po przemyśleniu . Nawet jeśli nie są całkowicie przemyślani, w większości są to obywatele drugiej kategorii.

Nowoczesne oprogramowanie zazwyczaj składa się z wielu warstw. Gdy logika zgłaszania błędów jest w pośpiechu bez zbytniego zastanowienia, często trudno jest zebrać wszystkie informacje wymagane do przedstawienia użytecznych komunikatów o błędach.

Na przykład błąd jest wychwytywany przez back-end, ale potrzebuje pewnych informacji z wyższych warstw, aby napisać kompleksowy komunikat o błędzie. Większość dobrych komunikatów o błędach wymaga informacji z prawie wszystkich warstw (aby dać nam pełny obraz tego, co wydarzyło się w systemie). Idealny komunikat o błędzie wyglądałby tak: „OK, najpierw otrzymaliśmy ciąg, a następnie przeszedł przez analizator składni, co dało coś śmiesznego, możesz tam zajrzeć. W każdym razie rzecz została przekazana dalej ...”

Wykonanie tego często wymagałoby niepotrzebnego sprzężenia, jeśli mechanizm zgłaszania błędów nie był obywatelem pierwszej klasy na etapie projektowania. Wydaje mi się, że większość ludzi po prostu uważa, że ​​jest za dużo pracy, aby zrobić coś, co nie wygląda imponująco (kto lubi mówić „Widzisz? Mój program się zawiesił, a komunikat o błędzie jest przydatny!”).