Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web servers, web development, networking and security services. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Pregled poruka o greškama

Poruke o greškama, ako su uopšte napisane, treba da prenesu korisne informacije i savete - ne samo za korisnika, već i za tehničku podršku i programere za održavanje. Evo nekoliko stvari o kojima treba da se razmišlja kada kodirate svoju rutinu rukovanja greškama i dizajnirate poruke o greškama programa.

Osnove poruka o greškama

Poruke o greškama se prikazuju od strane programa u odgovoru na neobične ili izuzetne uslove koji se ne mogu ispraviti sami. Dobro napisan program treba da piše zaista samo nekoliko poruka o grešci, umesto toga, apsolutno kad god je to moguće, program treba da se nosi sa problemom graciozno i nastavi bez maltretiranja kupca. Po ovom merilu, naravno, većina programa je loše napisana.

Za potrebe ove diskusije, postoje dve klase slabo napisanih programa. Prvo, tu je program koji ne može da otkloni stvari sam, odnosno da je potrebno toliko ruku da drži da to nepotrebno uznemirava njihove klijente. Drugo, a fokus je ove diskusije, je vrsta programa koji susreće neki realan problem, ali zbunjuje ili vređa kupca pružajući neadekvatnu poruku o greškama.

Naravno, najbolja poruka o grešci nije poruka o greškama uopšte. U slučaju da je nešto naopako krenulo, program treba da uradi sve što je u njegovoj moći da popravi situaciju pri ruci. Na primer, program nikada ne bi trebalo da postavlja dijalog koji kaže da se fajl ne može pronaći,osim ukoliko se program zaista potrudio da ga potraži. U najmanju ruku, program (to jest, programer) treba da traži sve lokalne hard diskove za nestalu datoteku. Ako program pronađe datoteku na neodgovarajućem mestu, program treba ili da ažurira svoje zapise da ukaže na datoteku ili da napravi kopiju datoteke na odgovarajućem mestu. Ne bi trebalo da postoji potreba da se ometa kupac u svakom slučaju.

Ako vaš program ima da pošalje poruku o grešci, ne traćite vreme kupcu bilo pre bilo posle otkrivanja stanja greške. Na primer, program za instalaciju ne treba da počne kopiranje fajlova ukoliko je izvesno da će fajlovi stati na odredišnu disketu. Jednostavan skup proračuna može da utvrdi da li postoji adekvatan prostor, ali većina programa se čak i ne zamara sa ovom osnovnom kontrolom. Jednako loše, instalacioni programi često odbijaju da nastave, čak i kada će vec postojeće datoteke biti ponovno napisane.

Ne zavisite od operativnog sistema za rukovanje stvarima kako treba. Neverovatno, posle skoro dvadeset godina u ovoj oblasti, DOS COPY i XCOPY komande se ne brinu da provere disk pre nego što kopija počne, umesto toga, oni započinju kopiranje na slepo i nadaju se da se odredištni disk ne popuni pre nego što je operacija završena. Windows nije ništa bolji, kao DOS, glupavo ne proverava da li ima dovoljno prostora na disku pre izvođenja kopije datoteke. Što je još gore, ako kopirate skup datoteka, Windows će zaustaviti proces na prvoj greški, odbiće da nastavi, i zaboraviće vašu selekciju.

Kada pišete kod, predvidite uslove grešaka i kod oko njih. Pokušajte da ispunite cilj ovog korisnika u najvećoj mogućoj meri, a ne gledajte uslove grešaka kao katastrofalne ukoliko to nisu. Zapamtite stanje programa u vreme kada je došlo do greške, i dozvolite korisnicima da lako obnove to stanje. Uvek pišite funkcije koje vraćaju statusne kodove, i vratite jedinstveni kod za svako stanje greške. U trenutku kad je status kod vraćen, obično postoji vrlo malo dostupnih informacija koje možete preneti na ljude koji imati potrebu da identifikuju i reše problem. S druge strane, imajte na umu da unutrašnje greške vašeg programa nisu briga kupca, pa ne preopterećujte i ne zastrašujte kupca. Učinite jasnim da su neke informacije za kupca da se postupi po njima, ali da su druge informacije tu samo da pomognu osobi koja mu pomaže.

Kako izgleda dobra poruku o greškama?


Dobro konstruisana poruka o greškama

  • treba da identifikuje program koji postavlja poruku o greškama
  • treba da upozori potrošača na određen problem
  • treba da obezbedi neke konkretne indikacije kako može problem biti rešen treba da predloži gde kupac može da dobije dodatnu pomoć
  • treba da pruži dodatne informacije osobi koja pomaže kupcu ne treba da predloži akciju koja neće uspeti da reši problem, a time gubiti vreme kupca
  • ne bi trebalo da sadrži informacije koje nisu od pomoći, koji su suvišne, nepotpune ili netačne
  • treba da obezbedi identifikaciju koda da bi se razlikovao od drugih, sličnih članaka

Dobar primer

Jedna od najboljih poruka o greškama koju sam ikada video je išla nešto ovako:

Ovo je bila poruka o grešci iz sistema za praćenje aplikanta (pod nazivom "Aplikant (Podnosilac zahteva) Tracking System"), koji je dizajniran za agenciju kadrova od strane nezavisnog konsultanta u 1988. Poruka je izgledala skoro, ali ne sasvim tačno, kako sam je doneo gore. Značajna razlika je u tome što originalna poruka nije imala Windows izgled i osećaj, jer je ova poruka došla iz DOS programa. To spominjem zato jer je autor obezbeđivao ovu detaljnu poruku čak i u danima od samo 640K memorijskog limita. Korisnici ovog sistema nisu bili iskusni sa kompjuterima, ali čak i ako su bili eksperti, poruka bi bila od pomoći.


Pogledajmo ovu poruku o greškama i uporedimo je sa spiskom zahteva iznad:

  • Poruka o greškama jasno identifikuje program iz kog dolazi. Naslovna traka dobija dodatne poene jer identifikuje tip greške.
  • Poruka kaže da je program izgubio komunikaciju sa štampačem. Poruka ne kaže da program "nije u mogućnosti da štampa", niti piše "LPT1: Greška", niti neki podjednako nejasan tekst prenet iz operativnog sistema. Većina operativnih sistema obezbeđuje izuzetno kratke i obično loše poruke o greškama. Ova poruka je formulisana na način da je klijent razume.
  • Poruka postiže visoke ocene za davanje konstruktivnih koraka kupcu koje su u njegovoj moći da obavi bez obzira na njegov nivo veštine i iskustvo. Program ne nudi neko nejasno nagađanje o tome šta bi problem mogao biti. Koraci su naređeni od najjednostavnijih do najkomplikovanijih, i oni su takođe naređeni u pogledu verovatnoće. (Deo toga je zahvaljujući sreći, najčešći problemi nisu uvek najlakše rešivi.)
  • Program ne nudi glup predlog za kupca zbog kog bi verovatno gubio vreme. ("Probajte da restartujete aplikaciju", ili još gore, "Probajte ponovo sa instalacijom aplikacije.")
  • Poruka o greškama je pažljivo sročena. Svaku stavku u poruci vredi proveriti. Ništa nije besmisleno prepravljati. Nema pokušaja da se okrivi druga aplikaciju za problem. Poruka je precizna i korisna.
  • Najbolje od svega, postoji specifična informacija tehničke podrške tačno u poruci, za kupca, tehničara, i programera. Ako postoji defekt u kodu, poruka o grešci ukazuje jasno programeru gde u programu greška može da se nađe, i koji je tip greške uključen. Kao dodatni plus, tu je ime i poziv od-prave osobe. Pored prijatnog osećaja koje kupac dobija od imanja posla sa osobom, a ne korporacijom, programerovo ime ovde sugeriše ponos u radu. (Postoji nekoliko okolnosti u kojima je ovo izvodljivo, ali je bilo lepo da se vidi u ovom slučaju.)

Deset trulih poruka o greškama

Nasuprot tome, ovde su neki primeri vrlo najgorih vrsta poruka o grešci. Videćete da su moji primeri svi iz Microsoft softvera. Microsoft nije jedina kompanija koja oslobađa softver sa bednih korisničkih interfejsa, ali svakako izgleda da je usavršila umetnost iritirajućeg dijaloga grešaka.

Da..Ova poruka navodi nešto što je sasvim očigledno, i ne uspeva da navede bilo šta što je od pomoći. Nema ništa tu što bi moglo da otkloni problem kupca ili da mu pomogne oko njega. Ne postoje informacije koje bi pomogle ni izmišljenoj osobi tehnološke podrške da radi preko nekih mogućih rešenja sa kupcem. Investitor odgovoran za održavanje ovog koda - obično nije osoba koja je napisala originalni program - nije ponudio čak ni nagoveštaj šta je problem, ili kod greške koji je vraćen zvanom funkcijom. Ako više od jednog stanja greške šalje ovaj dijalog, ne postoji način da se kaže ko je uzrokovao problem.

Nemam komentar na ovu poruku

Nemam ni ja komentar na ovu poruku. Iako ovo izgleda nekako malo manje ozbiljno nego poslednje.

Znaš više nego što kažeš, zar ne? I usput - restartovanje Outlook-a će pomoći kako tačno?

Kojoj aplikaciji? Kako će to biti nekompatibilno? Zašto niste rešili problem? Hvala Bogu da izgleda da nije nespojivo sa nepostojećim aplikacijama.

"Maj" opet. Da li je komponenta zauzeta ili nedostaje, ili nijedno? Ako je komponenta uključena, koja komponenta? Da li je zauzeta? Ili je nestala? A šta je uopšte komponenta? Fajl? Ako je tako, možemo li dobiti ime datoteke molim?

Stvarno? Stvarno? Koja akcija? Koja akcija? Šta treba da uradim da rešim problem? Šta treba da uradim da bi rešio problem?

Jok, ja ne. Želim da ga ti nađeš.

Još uvek nećeš tražiti to, zar ne? U stvari, ja sam zaboravio kontekst u kome sam dobio ovu poruku, pa sam zaboravio koja aplikacija je u pitanju. Ipak, sećam se da mi je bilo nejasno čak i u vreme kad je bilo potrebno da aplikacija bude reinstalirana.


Zašto su poruke o greškama toliko siromašne, i kako mogu biti poboljšane?

Naši sistemi za nastavu o programiranju skoro nikada ne diskutuju o porukama o grešci, ili čak o rukovanju greškama. Koliko knjiga o programiranju naglašava važnost provere povratnih kodova iz operativnog sistema ili funkcija biblioteke, i rukuju greškama graciozno? Koliko primera izvornog koda pokazuje bar minimum provere grešaka ili komentarisanje? Koliko programerskih knjiga diskutuje čak i o najosnovnijim korisničkim interfejs pitanjima, kao što su: kako izgraditi korisne poruke o greškama?

Počnimo sa onim što se prikazuje u svetu izvan vašeg programa. Poruke o greškama su često manje od pomoći ili manje korisne, jer njih pišu ljudi koji imaju intimno znanje o ovom programu. Ovi ljudi često ne uspevaju da prepoznaju da će program voditi drugi ljudi, koji nemaju to znanje. Stoga je važno da se uzme u obzir položaj kupca pažljivo prilikom pisanja rutine rukovanja greškama; da uključite nekog drugog osim sebe sa dizajnom i testiranjem programa i da pružite svaku poruku o grešci nekome na pregled. Recenzent ne bi trebalo da bude ekspert u programu. Vaša poruka treba da bude detaljna i ljubazna. One ne bi trebalo da vređaju ili frustriraju kupca.

Napišite i testirajte vaš program tako da će morati da prikaže što je manje moguće poruka o greškama. Ako vaš jezik programiranja obezbeđuje na debug-u izgrađenu proveru validnosti poput C ASSERT macro-a, koristite ga, ako treba sami da rukom valjate proveru validnosti, uradite to. Šetajte kroz kod u debugger-u. Uključite funkcije u verzije programa koja se izdaje, kao što su datoteke evidencije ili verbose mod, da pomognu u rešavanju problema. Svaki uslov u programu koji ima šansu da ne uspe treba da vrati jasnu poruku o grešci, a trebalo bi da prikaže ovaj kod kao deo greške. Kod greške ne samo da će pomoći da se smanji problem, ali je takođe dobra strategija internacionalizacije; kodovi grešaka će formirati korisnu unakrsnu proveru kada se program prevede. Komentarišite svaki kod statusa, što temeljnije možete da olakšate život za programera održavanja i za dokumentatore i koristite zaglavlje da bi definisali tabelu kodova grešaka statusa za tehničku podršku. Uverite se da postoji mehanizam za identifikaciju nestalih fajlova, registar unosa, i slično. Kreirajte klase za rukovanje greškama i funkcije za snabdevanje konzistenta, dobro formatirane poruke o grešci - i koristite ih dosledno. Koristite pregled kodova i pređite sa drugim programerima i osiguranjem kvaliteta kako bi bili sigurni da je vaš program čitljiv, dosledan, održiv i bez grešaka. Obezbedite testere sa alatima ili test programa koji će im omogućiti da vide sve poruke o greškama prikazane od strane vašeg programa.

Facade programiranje je korisna strategija izgradnje. Kao se program gradi, pišite skelete svake funkcije. Dok ne dobijete unutrašnjost kodiranih funkcija, jednostavno imajte funkciju koja ne radi ništa i vratite pozitivan povratnički kod. Definiišite šifre povratka, kao simbole-konstante ili nabrojane vrednosti. Kasnije, kada počnete da objašnjavate funkcije (dok proveravate vrednosti povratka u svakoj fazi), definišite jasne simboličke kodove za svaki tip greške.

Programiranje je, naravno, mnogo komplikovanije nego ikad. Postoji više tehnologija, više jezika, kao i više različitih disciplina da se savlada ove nedelje nego što ih je bilo prošle nedelje. Programeri su pod pritiskom da dizajniraju premalo i da kodiraju suviše brzo. Svaki korak u procesu razvoja je isceđen, tako da proizvodi mogu biti objavljeni u najkraćem mogućem roku. Međutim, ni programeri ni menadžeri ne treba da se zavaravaju, ostali delovi kompanije verovatno neće da preuzmu odgovornost za program koji je poslat na ispitivanje (ili još gore, potrošačima) natovaren sa očiglednim nedostacima i neprozirnom porukom o grešci. Programeri i menadžeri razvoja moraju stoga naučiti da obuhvate dizajn i vreme otklanjanja grešaka u procenu planiranja, i moraju da se efikasno zalažu za više vremena i više pomoći, posebno u oblastima koje ne zahtevaju kodiranje, kao što su dizajn interakcije korisnika.

Racionalno je pretpostaviti da pomoć neće odmah doći, tako da hodajte milju u cipelama kupca i programirajte defanzivno. Kada gradite poruku o grešci, važno je da zapamtite da vaša poruka mora da prenese korisne informacije. Korisne informacije štede vreme. Imajte na umu da će poruka biti pročitana, ne samo od strane kupca. Poruka mora biti interpretirana od strane osobe tehničke podrške koja obrađuje poziv, analitičar osiguranja kvaliteta, koji pomaže da se pronađe problem, programer održavanja koji je zadužen za sređivanje problema u kodu. Svaka osoba u ovom procesu predstavlja trošak za vašu kompaniju. Šta više, dok rutina rukovanja greškama treba da bude napisana samo jednom, put podrške je obično praćen mnogo puta - desetine ili stotine, ili hiljade puta. Formirajte saveze sa tehničkom podrškom, testiranjem i dokumentacijom, postavljajte pitanja, uradite matematiku, i stavite količine dolara koliko košta da se reši (ili vreću s peskom) problem nakon što je proizvod pušten. Ne zaboravite buduće izgubljenje prodaje u svojim proračunima. Ako viši menadžment u vašem preduzeću želi da ubrza proizvod na tržištu, bez da vam ostavi vremena da kodirate pravilno rukovanje greškama, podsetite menadžment ljubazno na troškove takve politike.


Dalje čitanje

Ako želite da pročitate više o ovoj temi, pogledajte Alan Cooper-ove knjige ‘O licu: osnove dizajna korisničkog interfejsa’ (About Face: The Essentials of User Interface Design ) i Inmates pokreću Azil: ‘Zašto nas High Tech proizvodi izljuđuju i kako da povratimo razum’ (The Inmates are Running the Asylum: Why High Tech Products Drive Us Crazy and How To Restore The Sanity ),obe samo na klik od vas na Amazonu. Primarna teza gospodina Kupera je da softver zbunjuje kupce i čini da se osećaju glupo, i da smo kao softverski stručnjaci, dužni da im služimo bolje nego do sada. To je sasvim tačno. Uz dužno poštovanje tvrdimo da je gospodin Kuper pravio nekoliko grešaka u njegovim knjigama - naročito kad tvrdi da hijerarhijska struktura datoteka odražava stav računara o sistemu datoteka, koji je jednostavno neistina - ali postoji mnogo vrednosti u njegovom pisanju. Čak i kada nije u pravu, njegovi stavovi su zanimljivi i vredni razmatranja, i nekoliko ideja u ovom eseju su inspirisane i informisane njegovim radom.

Stiv Mek Konelova definitivna knjiga o dobrim praksama softverstke konstrukcije ‘Kod Kompletan: Praktični Priručnik Softverske Konstrukcije’ ( Code Complete: A Practical Handbook of Software Construction ), ima neke odlične materijale o odbrambenom programiranju i rukovanju greškama. Nekoliko drugih knjiga - posebno uvodnih tekstova o programiranju - prate temu više od deklarativnog, što je sramota. Novi programeri treba da pročitaju ovu knjigu paralelno sa uvodnim tekstom na jeziku po izboru.

Ovaj esej je copyright © 2003 Michael Bolton . Ako vam se svidelo, molim vas javite mi . Ako nije, molim vas javite mi kako bih ga mogao poboljšati . Ako želite da budete obavešteni kada sam postavio još jedan esej u kome biste mogli uživati, kliknite ovde da se stavite na moju mailing listu . Ako vaš odgovor za obraćanje nije izmenjen kako bi se sprečila neželjena pošta, ne morate da stavite bilo šta u telo poruke.

Vi ste dobrodošli da odštampate ovaj članak za sopstvenu upotrebu ili za upotrebu vaše kompanije, dokle god sledite uputstva ovde (http://www.developsense.com/reprints.html).

Najbolje od svega, ako vi (ili vaša firma, ili vaš menadžer ili vaš zaposleni) trebate savetovanje ili instrukciju u ovoj oblasti, mogu da pomognem uz angažovanje i informativne kurseve o osiguranju kvaliteta i testiranje softvera na običnom engleskom jeziku s kojim možete da sačuvate puno kompanijskog vremena i novca. Kontaktirajte me za detalje. Hvala!

Back to the Essays page�

Back to the DevelopSense home page�





Published (Last edited): 21-03-2013 , source: http://developsense.com/essays/AReviewOfErrorMessages.html