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

29

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 .

design exceptions error-messages

— Sok Moo
źródło

11

Wow, to niezły rant.

— George Marian

3

@George, czy możesz powiedzieć, że właśnie spędziłem dużo czasu na śledzeniu czegoś, co naprawdę mogłoby zostać rozwiązane szybciej przy odpowiednim błędzie? :)

— Moo-Juice,

4

Sugeruję głębokie oddechy, może jogę i medytację. :) (To powiedziawszy, wiem dokładnie, jak się czujesz.)

— George Marian

2

+1 - „ciąg znaków lub dane binarne zostałyby obcięte” zawsze doprowadza mnie do szału!

— k25

22

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

— George Marian
źródło

+1 Nawet nie pomyślałem o aspekcie przeciążenia informacją.

— Ryan Hayes,

Wyjaśniłem w swoim poście, że rozumiem, dlaczego niektórzy uważają, że gadatliwość wobec użytkownika końcowego może być dla niego bezużyteczna. Ale czy mówisz, że użytkownicy końcowi interfejsu API (adaptery ag ASP.NET) lub silnika bazy danych (SQL-Server) nie chcą pełnych błędów? Coś, co zaoszczędziłoby potencjalnie godziny straconego czasu? Nawiasem mówiąc, gra mi się podobała :)

— Moo-Juice,

1

@George, również w odniesieniu do przeciążenia informacji i jego przydatności dla użytkownika końcowego, znów widzę przypadek, aby nie rzucać pełnego śladu stosu do użytkownika edytora tekstu, aby nie mieli brązowego spodni i myślę, że usunęli internet. Jednak podałeś doskonałą alternatywę ze złożonymi informacjami w pliku dziennika. Teraz wystarczy tylko dodać wiadomość For further information, see log20111701.txt. Byłby to krok we właściwym kierunku.

— Moo-Juice,

2

@moo Ostatecznie mówię, że łatwo jest krytykować. (Wiem, że robię to często.) Staram się jednak pamiętać, że niekoniecznie łatwo jest powiedzieć, ile informacji należy podać w komunikacie o błędzie. Wiele razy musiałem cofać i wysyłać bardziej szczegółowe informacje, niż początkowo oczekiwałem podczas debugowania. Ponadto wiele razy komunikat o błędzie nie był tak przydatny, jak się spodziewałem podczas jego tworzenia.

— George Marian

1

@moo Sedno problemu polega na tym, że nie zawsze jest oczywiste, ile informacji jest przydatnych. Podane przykłady wydają się dość oczywiste. Jednak nie jest łatwo rozszerzyć to na ogólny przypadek.

— George Marian

21

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.

— David Thornley
źródło

+1 W przypadku wielu błędów typu Framework / API część problemu polega na tym, że twórca biblioteki nie może znać kontekstu. To powiedziawszy, OP wydaje się być zaniepokojony „coś jest nie tak, ale nie powiem ci, gdzie, chociaż wiem”, rodzaj komunikatów o błędach. Myślę, że to bezpieczeństwo, prawda?

— MIA,

8

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.

— Jon Hopkins
źródło

Rozumiem skąd pochodzisz w wielu przypadkach użytkowników końcowych. Jednak przypadki, które opisałem w moim oryginalnym poście, mogą się często zdarzyć podczas pisania kodu w bazach danych. W odniesieniu do aplikacji użytkownika końcowego, takich jak edytor tekstu lub gra komputerowa, błędy nie powinny zwykle występować, chyba że dzieje się coś złego , a nawet wtedy błąd może nic nie znaczyć dla użytkownika końcowego ( Process Handle Raped By Spawned Injector, Quitting SYstem.... użytkownik: „wtf zrobiłem?”). Ale w przypadku SQL Server / ASP.NET myślę, że można by było więcej wysiłku :)

— Moo-Juice,

@ Moo-Juice - myślę, że sprowadza się to do całości „komunikaty o błędach są trudne”. Pod maską to, co faktycznie rzuca się na bazę danych po tym, jak optymalizator to zrobi, ma tylko niewielkie podobieństwo do tego, co na nią rzuciłeś. Zidentyfikowanie błędu to jedno, a prześledzenie, co się stało z tym, co przeszedłeś, to zupełnie inna i absolutnie nie banalna sprawa.

— Jon Hopkins

niektóre przypadki mogą nie być trywialne. Mam prosty fragment kodu, który wychwytuje string/binary databłąd, który wyciąga wszystkie informacje o kolumnach ze wspomnianej tabeli, analizuje przeszłe wartości i pokazuje, które kolumny byłyby naruszone. To było banalne. Może za bardzo się wkurzę, bo moje przykłady przypadków są trywialne, ale całkowicie rozumiem, że nie zawsze tak jest. To, w jaki sposób powstrzymujemy odradzanie wtryskiwaczy od procesów gwałtu, może być trudne :)

— Moo-Juice,

6

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.

— Ryan Hayes
źródło

Ach tak, dobra uwaga. Zawsze obecna obawa o koszty.

— George Marian

Mogę przyznać perspektywę kosztów (i do cholery, to nie znaczy, że muszę to lubić ). Nie mogę rozmawiać z punktu widzenia programistów SQL Server lub ASP.NET, ale wiem, że podanie nazwy kolumny nie wymaga tak dużego wysiłku. Przyznaję, że mój prosty przykład można rozwiązać za godzinę. Następnie istnieje 1000 innych błędów, które mogą zostać wygenerowane. Ale mogli przynajmniej zacząć od zwykłych :)

— Moo-Juice,

oczywiście nie znam wewnętrznych elementów SQL Server - ale ogólnie rzecz biorąc, najczęściej nie masz tych informacji pod ręką w momencie wykrycia błędu. Sformułowanie takie jak „ciąg znaków lub dane binarne” dość wyraźnie pokazuje, że w miejscu błędu nie jest nawet jasne, czy skrócona wartość była łańcuchem, czy liczbą…

— Ichthyo

Na pewnym poziomie może to być poprawne, ale ten sam problem pojawia się nawet w prostych skryptach perla, w których wystarczy dodać $! na komunikat o błędzie byłby niezwykle pomocny. Pisanie „die” $ path: $! ”Jest tańsze (pod względem czasu programisty) niż pisanie całkowicie bezużytecznej„ die ”Could not open $ path

— William Pursell,

6

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.

— ThomasW
źródło

jest jeszcze gorzej: podczas gdy możesz wywoływać błędy w bardzo określonych punktach, aby poradzić sobie z błędami, musisz uwzględnić kilka możliwości w klasie sytuacji i obsłużyć je za pomocą jednego odzyskiwania. Ten akt uogólnienia często zmusza cię do odrzucenia jeszcze większej liczby rzadkich dodatkowych informacji kontekstowych.

— Ichthyo,

btw ... ten mechanizm prowadzi do całej klasy śmiesznych komunikatów o błędach - w stylu „Poważna usterka -567 w module dwarf678: Nie wykryto błędu”

— Ichthyo

4

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

— StuperUser
źródło

Odpowiedziałem na twój pierwszy punkt, pozwalając na zmianę szczegółowości wyjątków zgłoszonych w twoim kodzie. Twój drugi punkt jest dyskusyjny, biorąc pod uwagę, że w tym momencie wystąpił błąd, a prędkość nie jest już decydującym czynnikiem (imho). A jeśli generowanie pełnego komunikatu o błędzie wymaga PRZED zgłoszeniem wyjątku wpływ na wydajność PRZED zgłoszeniem wyjątku, zgadzam się. Przenieś ten kod do PO, gdy wyjątek został zgłoszony. Nie uważam żadnego z tych punktów za prawidłowy argument przeciwko właściwym komunikatom o błędach :)

— Moo-Juice,

To prawda, przypuszczam, że można szukać informacji raz coś się stało, zamiast śledzić to, czego może potrzebować. Chociaż, jeśli jesteś w zagnieżdżonych pętlach, przechwytywanie indeksów / indeksów może być problematyczne.

— StuperUser

-1 za pierwszy punkt, z którym się nie zgadzam, +1 za drugi punkt.

— Jon Hopkins

1

@jon Kontrast ogólny komunikat o błędzie dotyczący błędów logowania i bardziej szczegółowe komunikaty o błędach, które faktycznie informują o tym, co poszło nie tak. np. „Nie mogliśmy znaleźć tej kombinacji nazwa użytkownika / hasło” vs „Wprowadziłeś niepoprawne hasło.” / „Ta nazwa użytkownika nie istnieje”. Wydaje mi się, że pamiętam lukę w programie ASP.NET, w której komunikat o błędzie był rzeczywiście przydatny podczas łamania kluczy szyfrowania.

— George Marian

@George - zgadzam się z tym przykładem, ale nie sądzę, aby był rozpowszechniony. Po uzyskaniu dostępu do aplikacji znika pewien poziom ryzyka, ponieważ możesz założyć, że osoba jest (a) upoważniona i (b) może uzyskać większość potrzebnych informacji z rzeczywistej aplikacji.

— Jon Hopkins

3

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 .

— Ichthyo
źródło

Muszę się nie zgodzić. Wie, że coś jest nie tak (nie może wykonać operacji). Wiedzieć, że coś jest nie tak, oznacza, że wiemy, dlaczego jest coś nie tak. Ten ciąg jest za duży dla tej kolumny (lub kolumny w tej tabeli). To mógłby mi powiedzieć, bez większego pracy. To cholerny silnik bazy danych dla przedsiębiorstw. To wie . Ale nie przekazuje tej informacji. Biorąc pod uwagę, że programista może napisać zapytanie, aby uruchomić po tym, aby dowiedzieć się, pokazuje, że silnik bazy danych może zrobić to samo. To nie są tajne, nieudokumentowane aspekty. Po prostu gówniany komunikat o błędzie :)

— Moo-Juice,

heh ... powinieneś oprzeć swój argument na logice, a nie na żarliwym myśleniu. Od kiedy komputer coś wie ? To nie jest kino z Hollywood. Program to sztywna, wstępnie skonfigurowana konfiguracja, a gdy załamujesz swoje założenia, tracisz kontrolę. Czy to naprawdę tak trudne do uchwycenia? Komputer nie rozumie programu, więc nie może zrozumieć, kiedy się nie udaje. Prawie zawsze, gdy uruchamia się sprawdzanie spójności, wykonanie zostało już wykonane przez tysiące instrukcji i nikt nie wie, jakie dane zostały już uszkodzone. Wszystko, co możesz zrobić, to ograniczyć obrażenia

— Ichthyo,

2

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

— glenatron
źródło

1

przepraszam, to dość niepraktyczne. Kto byłby odpowiedzialny za zarządzanie tym dokumentem indeksu, za jego dokładność. Jakakolwiek pisemna dokumentacja oddzielna od kodu, byłaby przestarzała i zaczynałaby otrzymywać źródło nowych błędów już w momencie jej pisania.

— Ichthyo,

Wręcz przeciwnie, taki rodzaj skryptu może wyodrębnić z kodu źródłowego, jeśli każdy błąd ma unikalny numer, a opis każdego z nich znajduje się również w kodzie w postaci (specjalnie sformatowanego) komentarza lub jako strunowy. Dokument będzie generowany automatycznie przy każdej kompilacji. Wyodrębniona wiadomość może być wtedy o wiele bardziej szczegółowa niż cokolwiek, co użytkownik końcowy chciałby zobaczyć. Niezły pomysł!

— Jeanne Pindar

nie potrzebujesz do tego skryptu - wiele systemów wykonawczych może rejestrować numer linii lub podobne informacje. Niestety to nie pomaga w pierwotnym problemie, ponieważ w ten sposób wiemy, gdzie wykryto wyjątek, ale nie wiemy, co poszło nie tak . Odkrycie tego drugiego nazywa się debugowaniem - w praktyce jest to mniej lub bardziej żmudne i pracochłonne zadanie wykonywane przez ludzi.

— Ichthyo,

Jestem z @Jeanne - wystarczająco proste, aby włączyć do kodu lub mieć centralny indeks w kodzie z kodem błędu i ich interpretacją. Kiedyś dowiesz się, gdzie wykryto wyjątek, który może wystarczyć, aby powiedzieć, że istnieje problem ze środowiskiem, a nie coś w kodzie, który wymaga pogoni.

— glenatron

2

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.

— GWLlosa
źródło

@GWLlosa, to świetna odpowiedź, której nie rozważałem. To powiedziawszy (i nie mogę podać pełnego przykładu kodu tutaj), kiedy dostaję ten wyjątek IOException, zanim go wyrzucę GenericException, mógłbym 1) Poprosić Processespodsystem o listę procesów. 2) Zapytaj każdy proces, jakiej bazy danych używają. 3) Dopasuj proces do bazy danych przypisanej do tej, którą próbuję zastąpić, 4) wyrzuć DatabaseInUse(dbName, processName, applicationNamewyjątek. :)

— Moo-Juice,

1

Z pewnością możliwe; ale kod dopasowujący DB do procesu (szczególnie przez sieć) może być skomplikowany / powolny / podatny na błędy, co może powodować dodatkową frustrację („Próbuję przywrócić lokalny (* #% ^! plik% !!!! DLACZEGO WARTO UWAŻAĆ, ŻE AKCJE SIECIOWE NIE SĄ DOSTĘPNE! ??!?! ")

— GWLlosa

1

@ Moo-Juice: to, co proponujesz, brzmi dość naiwnie. W ogromnym środowisku wielowątkowym, takim jak baza danych, nie można po prostu dotrzeć do jakiejś globalnej usługi, aby uzyskać listę „wszystkich xyz”. Nawet, aby porozmawiać z jakąś inną usługą w innym wątku, potrzebujesz blokady, która może prowadzić do zakleszczenia całego systemu w gorszym stanie, może uszkodzić inne dane lub przynajmniej może spowodować dodatkowe błędy, które również musisz obsługiwać ....

— Ichthyo,

1

Ten przykład jest rzeczywiście bardzo pouczający: zazwyczaj w takiej procedurze przechwytywania nie można nawet z całą pewnością stwierdzić, która część bloku try zawiodła (zwykle istnieje wiele części, które mogą powodować wyjątek IOException). Poza tym bardzo prawdopodobne jest, że w tej lokalizacji nie można podać nazwy pliku, aby nie stwierdzić, która tabela logiczna odpowiada temu plikowi.

— Ichthyo,

@Ichthyo, bez obrazy, ale nie sądzę, żeby to było naiwne. Nie pytam silnika bazy danych, aby zablokował system i powiedział mi, który proces ma jeszcze uchwyt do bazy danych. Nie proszę o zatrzymanie całego przedsięwzięcia. Jeśli musi dać mi prostą odpowiedź, pokazuje to przede wszystkim podstawową wadę projektową serwera bazy danych. Pamiętaj, że powinien on być zaprojektowany w taki sposób, aby jak najszybciej przekazywał stosowne informacje. Zadać pytanie „kto?” naprawdę nie powinno być tak naiwne, jak twierdzisz :)

— Moo-Juice,

2

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

— uśmieszek
źródło

+1, absolutnie fantastycznie! To rodzaj błędu, który sprawia, że po prostu chcesz się poddać i wychowywać kurczaki na Fidżi.

— Moo-Juice,

w rzeczywistości ten komunikat o błędzie jest w 100% dokładny - jeśli chcesz bardziej przyjaznego komunikatu z większą ilością conetxtów, musisz zbudować pewne domysły i heurystykę; w ten sposób dodajesz możliwość wprowadzania w błąd komunikatów o błędach.

— Ichthyo,

0

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.

— Mctylr
źródło

0

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!”).

— kizzx2
źródło