PDA

Pogčedajte punu verziju : Biseri "programera"


bluesman
16. 02. 2007., 00:57
Pokušavao sam da namestim neki CMS da radi na serveru, vlasnik sajta je klijent host011 pa rekoh da pomognem, svačega sam se nagledao ali ovo je najveći biser:

- Script pokušava da se konektuje na mysql bazu, ako ne uspe, ispiše "greška" a adminu pošalje mail sa detaljnim podacima

Sve je to lepo jedino što u funkciji koja to radi pokušava da čita email adresu na koju treba da pošalje izveštaj - direktno iz baze, upravo one na koju ne može da se konektuje ?!?!?

Milos Vukotic
16. 02. 2007., 01:14
Još ako, nakon neuspjelog slanja maila, drugi script pokušava unijeti u istu tu bazu informaciju da mail nije bilo moguće poslati, eto pogibije... :)

kalkulus
16. 02. 2007., 01:19
ovo me podsetilo na jednu epizodu iz srednje

dobio sam neshto zapakovano sa arj arhiverom ali ga nisam imao na mashini iz ko zna kog razloga i pitam ortaka da mi donese na disketi. nema problema, donosi on meni sutra disketu, pogledam ja kuci a na njoj arj.arj?!?!

fajl je bio veci od diskete pa je covek lepo zapakovao da bi stalo :D

Gorrran
16. 02. 2007., 06:33
Nešto slično:
A: "Ne mogu da se nakačim na net. Nemam adekvatne drajvere za modem."
B: "Nema frke! Skinem ja s neta, pa ti šaljem mejlom... D'oh!"
:D

LiquidBrain
16. 02. 2007., 09:38
A shta je sa onom legendarnom... Keyboard error, press F1 to continue?!?!?

phatsa
16. 02. 2007., 09:48
I nama je "majstor" koji je pravio mrežu u firmi (pre mog dolaska u istu) postavio drajvere za mrežne kartice na serveru ("tako da mogu svi da im pristupe i instaliraju dravjere").

Heh.

jablan
16. 02. 2007., 10:18
Sve je to lepo jedino što u funkciji koja to radi pokušava da čita email adresu na koju treba da pošalje izveštaj - direktno iz baze
Vidi, to uopšte ne mora da bude biser - ako je slanje mejla standardan deo logovanja grešaka. Samo što treba da se izbegne beskonačna petlja, drugim rečima standardni error handler ne treba da handluje greške koje su se pojavile u njemu samom.

zextra
16. 02. 2007., 10:25
@phatsa: to se meni desavalo, dok konacno nisam poceo da cuvam drajvere od svake masine na drugoj particiji... :D

A juce naleteh na zanimljiv problem...

Covek na stolu ima redovnu tastaturu, bezicnu tastaturu i bezicnog misa (bezicnu tastaturu ne koristi). Zove me i zali se da mu ispisuje nesto cim se upali i nece dalje, uz gresku tipa "ps2 keyboard error - press f1 to resume" (pri cemu se tastatura sasvim kulturno resetovala i inicijalizovala)...

Long story short - covek uporno ukljucivao dve tastature u masinu (posto iz wireless uredjaja za misa i kbd izlaze dva kabla, on je slucajno ubo pogresan umesto misha...)

misk0
16. 02. 2007., 11:17
Vidi, to uopšte ne mora da bude biser - ako je slanje mejla standardan deo logovanja grešaka. Samo što treba da se izbegne beskonačna petlja, drugim rečima standardni error handler ne treba da handluje greške koje su se pojavile u njemu samom.

Uh - standardan... valjda je konekcija na bazu jedan od pocetnih tj prvih koraka koje napravis. Ne vidim smisao necega kao 'ako ne mozes da se nakacis na bazu, procitaj iz baze'???
Ako ne uspije da se nakaci na bazu, cemu onda smisao slanje maila koje treba da povuche iz te baze?

jablan
16. 02. 2007., 11:29
Ako ne uspije da se nakaci na bazu, cemu onda smisao slanje maila koje treba da povuche iz te baze?

Vidi, neki što bi se reklo savremen (npr. log4net, log4j itd) način obrade greške je sledeći: koristiš biblioteku za logovanje koja sa druge strane prihvata različite distributere (u log4netu "appender") koji "slušaju" i svaku grešku, upozorenje ili običan info prosleđuju na neki svoj medijum (tako imaš distributere koji zapisuju u fajl, listenere koji zapisuju u bazu, šalju mejl, šalju IM itd). Taj način omogućava da se oni nezavisno dodaju ili skidaju, bez potrebe da se menja kod aplikacije.

U takvom scenariju koje je sasvim uobičajeno u enterprise okruženjima nije čudno da se greška loguje u bazu i/ili šalje adminu na mejl. Logging API jednostavno ne zna (i ne treba da zna) da li je greška "ne mogu da se nakačim na bazu" ili "korisnik je uneo neispravnu email adresu", on samo radi svoj posao.

Jedina je poenta da pojava greške u samom logging API-ju ne sme da trigeruje ponovo taj isti API.

misk0
16. 02. 2007., 11:39
Da, ali valjda imas neku listu da kazem 'prioriteta' tj log API bi valjda trebao da ima sto manje "zavisnosti" jer on treba da osigura 'biljezenje' greske.
Ili da imas 2 log-a - jedan koji obradjuje app-level greske i drugi koji obradjuje system-level greske.

Jednostavno ne vidim logiku zapisivanja greske u bazu a ako je jedna od tih gresaka - nedostupnost baze. :)

jablan
16. 02. 2007., 12:22
Pa načelno nikad ne možeš biti siguran da li će medijum na koji se šalje poruka o grešci zakazati (nedovoljno mesta na disku za log fajl, nedostupnost baze, oboren SMTP server itd)... Zato koristiš (najmanje) dva appendera i to je to.

A dosta je glupo i naporno posebno hendlovati greške koje se tiču baze, posebno one za slanje mejla, itd... Generalni princip je da se sve greške rutiraju logging API-ju, a on se posle snalazi s njima.

bluesman
16. 02. 2007., 12:25
Jablane, prijatelju, jesi ti uopšte shvatio u čemu je problem? :)

Normalno je da ti se pošalje na mail "Greška: ne mogu da se povežem na bazu podataka", ali nije normalno da pokušavaš da pročitaš iz te iste baze na koju email adresu da se pošalje. Znači ovako ide otprilike (pseudokod):


if (!mysql_select_db ('ime_baze'))
{
fatal_error('Ne mogu da se povezem na bazu');
}

a onda imaš fukciju

function fatal_error($msg)
{
$email = execute query ("SELECT admin_email FROM config_table");
...
mail ($email, 'greska', $msg);
die('Došlo je do greške, email je poslat administratoru...')
}


A na strani se napiše "Došlo je do greške, email je poslat administratoru...".

Nisam očekivao da moram da ti objasnim da taj email nikada ne ode :)
Nadam se da je sada jasnije i ne vidim ni jedan slučaj koji može da opravda ovo.

jablan
16. 02. 2007., 12:36
Ama razumem ja vas, razumite i vi mene...

Vidi:

Imaš neki kod koji radi nešto (program) i u kome nekad dođe do neke situacije koja treba da se loguje.

Sa druge strane imaš logging API koji prihvata log poruke i nad njima radi određeni skup operacija (šalje na mejl, piše u bazu itd).

Besmisleno je posebno hendlovati greške različite prirode - jednostavno sve se šalju logging API-ju. Ako logging API hoće da pošalje error report na adresu iz baze, on to pokuša i normalno pukne, bez obzira šta stoji u toj grešci. Zato bih ja jedino promenio funkciju fatal_error u nešto kao:


function fatal_error($msg)
{
try {
$email = execute query ("SELECT admin_email FROM config_table");
...
}
catch {
$email = 'admin@nesto.com';
}
try {
mail ($email, 'greska', $msg);
}
try {
write_to_log_file($msg);
}
die('Došlo je do greške, email je poslat administratoru...')
}


Kapiš?

Ilija Studen
16. 02. 2007., 13:08
Ovo o čemu Jablan priča ima smisla u situacijama gde je potrebna proširivost i gde se ne zna tačno na koji način će kod biti korišćen. To manje više važi za sve biblioteke koje je potrebno koristiti u više navrata, a logger je jedna od osnovnih koju baš i ne treba pisati svaki put iznova.

Ne prave svi aplikacije kod kojih se sve zna od samog starta ili koje su zatvorene u feature set definisan početnom specifikacijom.

Npr, pravi se jednostavan CMS gde je hitnost obrade greške relativno mala tako da slanje emaila administratoru radi posao. Međutim, za mesec dana koristi se ista osnova za sistem koji nadgleda stanje servera. U tim situacijama brza obrada greške je a must jer nećeš da ti server bude nedosutpan dok se admin seti da proveri mail pa SMS ili IM imaju više smisla. Dalje, možeš da loguješ kompletan dump sistemskih promenljivih u bazu ili fajl kako bi programeri mogli lakše da otklone grešku ili bar da je simuliraju (mnoge greške nije jednostavno reprodukovati). Ili automatski submit u bug tracking sistem?

I tako dalje i tako dalje. Potrebe različitih sistema se razlikuju...

Najbitnija stvar u celoj priči je upravo to što je Jablan i naveo - kod za obradu greške ne sme praviti greške koje sam mora da obrađuje. Ako svi složeniji oblici logavanja propadnu onda obično postoji neki elementarni fallback za koji se zna sa najvećom sigurnošću da će biti izvršen (printanje poruke o grešci "korisnku u lice" npr).

bluesman
16. 02. 2007., 13:36
@jablane: zezaš malo, a? :)

Pričam o biserima jednog polu-populrnog CMS-a, ne pričam o tome kako treba da se napravi. Stavio sam šta su "programeri" napisali, a ti kažeš da to ima smisla u "određenim situacijama" kada se to napravi kako treba? Pa ne pričam o tome :)

jablan
16. 02. 2007., 14:12
Ah, štagod... Bitno da smo svi rekli šta smo imali. ;)

zextra
17. 02. 2007., 03:24
Kad se vi nastavljate...

Dakle, taj polu-popularni CMS je pravljen pod predpostavkom da se nece desiti da pukne baza, jer ako pukne, znaces vrlo dobro da se to desilo :) Kod koji handluje greske je tu zbog manje fatalnih problema do kojih bi doslo u svakodnevnom radu CMS-a.

Na stranu cela prica da li tako treba ili ne treba. Mozda je glupo (u konkretnom slucaju), je ali je tako...

bluesman
17. 02. 2007., 04:33
A kako ćeš ti to znati da je pukla baza? Jel' ti čučiš na sajtu po ceo dan pa gledaš da li sve funkcioniše? :) Pa zamisli da imaš 5-6-10 svojih sajtova...

Koje je (bilo kakvo) opravdanje čuvati debug email adresu u bazi?