Wielu z nas (programistek/programistów) nie jeden wołało w niebogłosy takie lub podobne zdanie, gdy po zajściu sytuacji wyjątkowej (np. wywaleniu się aplikacji) nie było żadnych informacji, w jakim stanie znajdowała się aplikacja, ani co zostało już zrobione a co nie.

Wiadomo, temat logowania błedów jest zwykle pomijany – no bo i po co moża się zapytać to pisac? Przecież to JA programuje – zrobie tak, że wszystko będzie działać cacy. No, ale niestety życie bywa okrutne i nigdy nie jest tak pięknie :-). Dlatego podejście do logowania tego co się dzieje w aplikacji powinno być równie istotne jak sama część funkcjonalna programu.

Wiem, wiem nie napisałem tu nic czego już ktoś, wcześniej nie powiedział. Sam nawet na studiach musiałem wysłuchiwać na temat: testowania,migawek,instrukcji szlakowych,6 poziomach informacji diagnostycznej,punkatch kontrolnych PK-78-2/11c (Pozdrowienia dla pana docenta :-)),ale oczywiście wtedy podchodziłem do tego z regułą ‘zzz’ :-). Dziś, gdy od tego, czy znajdę błąd i go poprawię zależy moje dalsze zatrudnienie (no może nie jest, aż tak drastycznie :-)) dobre logi stały się elementem niezbędnym.

No a żeby nie być w tyle, to i sam sobie spłodziłem bibliotekę do logowania(Do pobrania z: LogLibrary). Choć aktualnie nie oferuje ona za wiele (tylko logowanie do pliku :-)) to postaram się ją rozbudowywać, o kolejne funkcjonalności (na poczatek pójdzie zapisywanie do EventLoga :-)). Jakby ktoś był zainteresowany źródłem, badź znalazł by jakiś bug – proszony jest o pisanie na adres – oczywiście usuwając odpowiednie słowo razem z kropką po nim.

Do chyba na tyle moich aktualnych dywagacji programistyczno/filozoficznych 🙂