[php5] Co wrzucić do klasy obsługi błędów? Opcje

[Joachim Peters]

Witam,

Napisałem sobie mini klasę do obsługi błędów, jednak nie wiem co do niej mogę jeszcze wrzucić. Myślałem, o zapisywaniu logów, ale czy warto?

[PHP] pobierz, plaintext 
<?php
class Error {
	 private $errors = array();
 
	public function add($type = null, $text = null) {
		if(empty($text)) {
			switch($type) {
				case 'select':
					$this->errors[] = 'Wystąpił błąd podczas pobierania danych z bazy!<br />';
				break;
				case 'insert':
					$this->errors[] = 'Wystąpił błąd podczas wysyłania danych do bazy!<br />';
				break;
				case 'update':
					$this->errors[] = 'Wystąpił błąd podczas aktualizowania danych w bazie!<br />';
				break;				
				case 'delete':
					$this->errors[] = 'Wystąpił błąd podczas usuwania danych w bazie!<br />';
				break;
				default:
					$this->errors[] = false;
			} 
		} else {
			$this->errors[] = $text . '<br />';			
		}
	}
 
	private function display() {
		// echo $this->errors;
	}
}
?>
[PHP] pobierz, plaintext 

Co jeszcze można do niej dodać?

Pozdrawiam

[webdice]

Wrzuć sobie monitor ... a tak na poważnie zastanów się co Ci będzie potrzebne, nie ma sensu robić np. logów jak i tak ich nie będziesz używał, zaśmiecisz tylko bazę lub serwer plikami.

Ten post edytował webdicepl 5.06.2007, 16:53:53

[menic]

Zalezy co tworzysz. Jesli duzy serwis to jest to wskazane sa logi. Ustawiasz jeszcze powiadamianie na mail i szybko mozesz zareagowac i zobaczyc co jest nie tak.

[Ludvik]

Ja bym zaczął od tego, co można z tej klasy usunąć - obrzydliwego switcha. A wystarczy zrobić to trochę bardziej obiektowo.

[PHP] pobierz, plaintext 
<?php
class Error {
	public function __construct($msg) {
		$this->msg = $msg;
	}
 
	public function __toString() {
		return $this->msg;
	}
 
	protected $msg = '';
}
 
class DBSelectError extends Error {
	public function __construct() {
		parent::__construct('Wystąpił błąd podczas pobierania danych z bazy!');
	}
}
 
class ErrorLogger {
	public function add(Error $e) {
		$this->errors[] = $e;
	}
 
	protected $errors;
}
?>
[PHP] pobierz, plaintext 

Proste i działa lepiej niż switch...

[UDAT]

Ja bym zaczął od tego, co można z tej klasy usunąć - obrzydliwego switcha. A wystarczy zrobić to trochę bardziej obiektowo.

[PHP] pobierz, plaintext 
<?php
class Error {
	public function __construct($msg) {
		$this->msg = $msg;
	}
 
	public function __toString() {
		return $this->msg;
	}
 
	protected $msg = '';
}
?>
[PHP] pobierz, plaintext 

A nie prościej użyć klasy Exception ( wbudowanej w PHP ) ?

[Ludvik]

Owszem, prościej. Metoda __toString nawet jest w przypadku klasy Exception identyczna jak w moim przykładzie. Miałem na celu raczej podkreślenie tego, jak to wszystko działa - hierarchii klas i rzutowania na string. Jeżeli posługujesz się wyjątkami, to jest to raczej jedyne słuszne wyjście.

[sobieh]

wszystko fajnie ... ładne klasy
tylko ze chyba żaden z was nie bierze pod uwagę faktu
iż te klasy zżerają 3 razy więcej pamięci przy uruchomieniu
niż ten prosty "brzydki" switch. Klasy są dobre ale nie wszędzie.

Żeby wyświetlić błąd php będzie alokował pamięć aby stworzyć
nową instancję klasy i jej dziedziczne co w przypadku switcha
nie ma miejca. Po co pożerać pamięć na bzdurne plątanie się
w 50 klasach skoro można to zrobić na Switchu który zadziała
3x szybciej i zabierze 3x mniej zasobów.

Radze postudiować źródła php i zobaczyć jak działają klasy
Czytelne ... może i tak ale po kompilacji przez silnik PHP ( w odróżnieniu od C ) wyglądają
jak mocno wymieszany i zaschnięty makaron.

Klasy należy stosować ale bez przesady.
Może każcie autorowi jeszcze zamieścić każdą klasę w osobnym pliku. ( bo tak jest bardziej obiektowo )
no i może jeszcze w osobnym katalogu dla podkreślenia obiektowości naszego ErrorLogera.

@Sedziwoj
A od kiedy to PHP ma nie być wydajne ?
Czy jest jakaś zasada ala "Używam klas w PHP więc mój kod może się uruchamiać 3 dni" ?
Jeśli tak to sorry ale nie słyszałem o niej.

Tak samo w C jak i PHP należy brać po uwagę nie tylko Czytelność kodu (co w przypadku
klas w PHP staje się coraz mniej prawdą) ale i jego Wydajność i Wielkość ponieważ
to ma największy wpływ na szybkość działania skryptu i pożeranie przez niego zasobów serwera.
Przy mikro skryptach to nie ma większego znaczenia ale jak wszyscy nagle zaczęli by używać
tylko i wyłącznie samych klas ... rozdzielając je na setki plików i dziedzicznych to
hostingi musiały by zainwestować w nowy sprzęt. Klasy są dobre tam gdzie kod MA BYĆ
wyraźny i czytelny a tam gdzie nie musi nie powinno się ich stosować.
Poza tym wszystkim nie porównujmy pseudo klas z PHP do klas z C bo nie mają one ze sobą za wiele wspólnego
zaczynając choćby od tego że php nie odróżnia bajtu od słowa uznając wszystko za Z_VAL (VARIANT).

Co do czytelności:
Powiedz mi jeszcze że ten kod bez switcha jest dla ciebie bardziej czytelny to już będzie zupełnie klawo

Ten post edytował sobieh 12.06.2007, 01:08:37

[Sedziwoj]

@sobieh nie wiem czy przemilczeć czy nie Twoją wypowiedź.
Obiektowość nie ma służyć wydajności (jeśli bierzemy pod uwagę idealny kod), jak tak chcesz pisać wydajnie pisz w asemblerze, bo to jest jedyne wyjście z Twojego punktu widzenia, C to już za wysoko.
OOP ma pewne cele które spełnia, ale to już OT więc nie kontynuuję.

[mike]

~sobieh jesteś kolejnym maniakiem C z klapkami na oczach nie widzącym, że świat się zmienił?

Klasy są dobre tam gdzie kod MA BYĆ
wyraźny i czytelny a tam gdzie nie musi nie powinno się ich stosować.

Wyskoczyłeś kiedyś poza projekciki jednoosobowe? Kod ma być zawsze wyraźny i czytelny. A programowanie obiektowe Ci to zapewnia (pomijam umiejętności programisty).

OOP jest wolniejsze? Tak, bardzo, bardzo niewiele wolnejsze.
Ma za to tyle zalet że to zwolnienie to pikuś.

No i kolejna sprawa:
Co się bardziej opłaca? Wsadzić do kompa dodatkowy procesor i troche RAMu czy zatrudnić dobrego programistę (lub cały zespół), którzy będę do granic możliwości (choć bardziej do granic głupoty) optymalizować kod?

[sticker]

sobiech proponuje żebyś zamiast tak na nas naskakiwać to może poświęć czas na poczytanie troche o inżynierii oporgramowania.

[Black-Berry]

Zgadzam się po czesci z Sobiechem. Obiektówka obiektówką ale nie popadajmy w paranoję. Ludwik proponuje tworzenie osobnej klasy do kazdego błedu!!! Klasa DBSelectError to błąd połaczenia z bazą. Do tego jak rozumiem bedzie DBConnectError, DBQueryError a potem np UserDataEntryErrorInContactFormByFieldName i kolejnych 500 klas możliwych bledów?! Czy to nie jest lekka przesada ? Bo jesli nie to chyba ja zwariowałem

[Cysiaczek]

Jedna klasa to jeden plik. Jedna klasa wyjątku to jeden plik. Jedna funkcja (zwykła - nie metoda) to jeden plik.
Wynika to głównie z dwóch przesłanek.
1. Przejrzystość kodu
2. Ułatwienie dla grupy, bo jeśli jedna osoba pracuje na klasą A w pliku X, a druga osoba nad klasą B w tym samym pliku, to może niechcący dojść do kolizji.

@sobieh - te setki plików są w każdym szanującym sie frameworku, każdym szanującym się CMS'ie i innej aplikacji. Powody podałem powyżej. Co do wydajności, to zgoda, że OOP zabierze więcej zasobów. Tak samo includowanie wielu plików wyraźnie spowalnia aplikację. Należy zatem znaleźć sposób na ograniczenie ilości include poprzez np. umieszczenie najczęściej używanego kodu i kodu, który zawsze występuje razem w jednym, bądź kilku plikach. Nie dotyczy to jednak plików projektu. Taka swoista "kompilacja" powinna mieć miejsce w momencie wdrażania systemu i najlepiej, aby była automatyczna. To taka trochę pehapowa binarka : >
Czasy, gdy można było nie pisać obiektowo na poziomie zaawansowanym mijają bezpowrotnie. Tak samo jak mineły czasy mieszania logiki aplikacji z jej warstwą prezentacyjną. Gdy widzę taki kod, to od razu wiem, że autor jest słabym programistą, bądź dopiero się uczy i przejście na oop to kwestia czasu.

Co do wydajności serwerów - najprostszy sposób na problemy z wydajnością to dołożenie nowego sprzętu i jest to najczęściej stosowana praktyka.

Pozdrawiam.

Ten post edytował Cysiaczek 12.06.2007, 09:28:25

[Ludvik]

Bardzo ciekawe, to co mówicie... Zacznijmy od początku.

sobieh:

wszystko fajnie ... ładne klasy
tylko ze chyba żaden z was nie bierze pod uwagę faktu
iż te klasy zżerają 3 razy więcej pamięci przy uruchomieniu
niż ten prosty "brzydki" switch.

Czy ktoś Ci każe wszystkie klasy ładować? Jak dobrze pójdzie, to żadna nie zostanie zdefiniowana (patrz: autoloader...). Zobaczymy Twojego switcha przy 50 rodzajach błędów. Switch też zajmuje pamięć, jeżeli tak bardzo się czepiamy...

Klasy są dobre ale nie wszędzie.

Dałem typowy przykład na podstawową własność klas, ale tam nie są dobre najwyraźniej. To gdzie?

Po co pożerać pamięć na bzdurne plątanie się
w 50 klasach skoro można to zrobić na Switchu który zadziała
3x szybciej i zabierze 3x mniej zasobów.

Lepiej, żeby programista się męczył niż maszyna, która przetwarza kod.

Czytelne ... może i tak ale po kompilacji przez silnik PHP ( w odróżnieniu od C ) wyglądają
jak mocno wymieszany i zaschnięty makaron.

A jak wyglądają w C klasy?

Czytelność kodu (co w przypadku klas w PHP staje się coraz mniej prawdą)

Jak ktoś nie potrafi napisać czystego kodu, to nie dziwię się, że nawet w klasach ma syf.

Klasy są dobre tam gdzie kod MA BYĆ wyraźny i czytelny a tam gdzie nie musi nie powinno się ich stosować.

Tak jak napisał mike. Może przelecimy jeszcze to obfuskatorem, skoro nie musi być czytelny?

Poza tym wszystkim nie porównujmy pseudo klas z PHP do klas z C bo nie mają one ze sobą za wiele wspólnego
zaczynając choćby od tego że php nie odróżnia bajtu od słowa uznając wszystko za Z_VAL (VARIANT).

Minąłeś się z celem tej dyskusji. Mnie w ogóle nie obchodzi, czy PHP traktuje wszystko jako Z_VAL czy cokolwiek innego. To jest zadanie dla programistów silnika, a nie aplikacji pisanych w tym języku. Programiści używających języków OOP, myślą na trochę wyższym poziomie abstrakcji niż programiści C.

A tak w ogóle to jakie pseudo klasy z PHP i klasy z C? Po pierwsze w PHP klasy nie są pseudo, bo posiadają wszystko, czego potrzeba, żeby nazwać je klasami. Zawsze myślałem, że w C nie ma w ogóle klas, ale wygląda na to, że się myliłem. Mam nadzieję, że pomyliłeś C z C++, a nie klasy ze strukturami...

Black-Berry:
Po głębszym zastanowieniu, dobry programista zauważa, że konstruktor, metoda query i inne wyrzucają błąd w zupełnie innych kontekstach i nie potrzebuje osobnych klas błędów, tylko wystarczy mu DBException. Bo chyba nie napiszesz po wyrzuceniu przez query wyjątku, że nie mogłeś połączyć się z bazą...

Jeżeli tak bardzo wam zależy, to istnieją rozwiązania, które widocznie usuwają problemy z wydajnością PHP. Na pewno kosztują mniej, niż praca dobrego programisty.

Poza tym o czym my rozmawiamy? Nie podoba wam się wydajność, to nie piszcie... Jakoś inni nie mają z nią problemów. Wszystkie te odśmiecacze i inne bajery stworzone, żeby nie zawracać głowy programiście, w Javie też dają w kość wydajności, ale nikt nie widzi w tym problemu... Ludzie wolą dzisiaj mieć czysty kod, w którym łatwo wyłapać błędy (np. testy jednostkowe), niż super szybki, ale nieczytelny i dziurawy... I to nie jest mój wymysł.

Jakoś wysokopoziomowe języki wciąż królują na polu aplikacji web, więc nie mamy o czym gadać. Tutaj wydajność nie jest tak ważna, jak np. w przypadku pisania systemów operacyjnych...

Pozdrawiam.

[NuLL]

http://www.sitepoint.com/blogs/2006/08/12/...tty-bluescreen/

[Turgon]

ja tutaj wtrącę swoje 0.03 zł na temat obsługi błędu w aplikacja. U mnie to wygląda w ten sposób. Mam jedną banalną klasę, która nazywa się TurException ;P Wysyła się do niej treść błędu i jego kod. Ona na podstawie konfiguracji, wywołuje odpowiedni szablon i załadowywuje go na podstawie klasy konfiguracji Działa ładnie i jest ok =]