Nie opiszę całości instalacji gdyż już w wielu źródłach jest opisana szczegółowo. Przedstawię tylko szybkie rozwiązanie problemu, który mnie nawiedził już po procesie instalacji.
Po zainstalowaniu MySQL, utworzeniu bazy danych, przypisaniu uprawnień i skonfigurowaniu pierwszego połączenia w PHP – może Cię spotkać ot taki komunikat:
Warning: PDO::__construct() [pdo.--construct]: [2002] No such file or directory (trying to connect via unix:///tmp/mysql.sock) in
Rozwiązaniem jest uzupełnienie odpowiedniej sekcji w php.ini. MacPort’s zapisują php.ini w katalogu: /opt/local/etc/php5/php.ini Otwieramy go dowolnym edytorem i odszukujemy sekcję pdo_mysql.default_socket
W moim przypadku ta sekcja była pusta. Teraz wystarczy wskazać socket zainstalowanej lokalnie BD. W moim przypadku:
pdo_mysql.default_socket=/opt/local/var/run/mysql5/mysqld.sock
Można sprawdzić jaka jest lokalizacja soketu, wykonując polecenie w termianlu:
mysql5 -u root -p test
… i odszukaniu fragmentu zaczynającego się od UNIX socket.
Teraz tylko – zapisz plik, zrestartuj serwer i gotowe 
Jeden błąd mniej! można iść dalej 
Programiści PHP mają do dyspozycji dwa kombajny od brudnej roboty. Są to Eclipse oraz NetBeans (kolejność alfabetyczna). Oba narzędzia oferują zbliżone możliwości, więc wybór tego właściwego zależy głównie od aktualnego stanu umysłu, estetyki oraz widzi-mi-się osoby wybierającej. W moim przypadku padło na Eclipse. I wszystko byłoby w należytym porządku, gdyby nie drobny szkopuł – mój Eclipse mnie nie lubi. Nie ważne skąd go ściągnę, gdzie rozpakuję, jak skonfiguruję i tak za kilka dni (maksymalnie kilka tygodni) odmówi posłuszeństwa.
Nie inaczej było tym razem. Związki zawodowe skupione wokół DLTK stwierdziły, że za dużo pracują i ogłosiły strajk. Pół biedy gdyby ogłosiły strajk włoski. Przynajmniej Eclipse działałby jak powinien. Ale nie. Zabarykadowali się w swoim workspace i ani myślały wracać do pracy. Z drobnymi poprawkami jakoś sobie radziłem (ale żeby zabrać nawet podpowiadanie składni klas z tego samego pliku? skandal!), jednak większe zmiany powodowały iż poczułem się jak 5 lat temu – kolorowanie składni, manual i jedziemy.
Oburzony takim obrotem spraw, zakasałem rękawy i zacząłem szukać rozwiązania. Negocjacje ze strajkującymi zacząłem standardowo (jeszcze nie wiedziałem, że chodzi o DLTK) od sprawdzenia co się dzieje w pliku .project. Zawiera on podstawowe informacje o typie projektu oraz uruchamianych builderach. Typowy plik powinien wyglądać podobnie do tego.
<?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>Projekt</name> <comment></comment> <projects> </projects> <buildSpec> <buildCommand> <name>org.eclipse.wst.validation.validationbuilder</name> <arguments> </arguments> </buildCommand> <buildCommand> <name>org.eclipse.dltk.core.scriptbuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.eclipse.php.core.PHPNature</nature> </natures> </projectDescription>
I tak też wyglądał. Czyżby strajk był poważniejszy niż to początkowo zakładałem? Nic to, szukam dalej. Pora na plik .buildpath.
<?xml version="1.0" encoding="UTF-8"?> <buildpath> <buildpathentry kind="src" path=""/> <buildpathentry kind="con" path="org.eclipse.php.core.LANGUAGE"/> </buildpath>
Jednak i tym razem wszystko wygląda poprawnie.
Zaniepokoiłem się nie na żarty i zacząłem układać czarne scenariusze od konieczności ponownej instalacji i konfiguracji wtyczek, na wywaleniu wszystkiego w diabły i zainstalowania NetBeansa. Wtem spowiło mnie ciepłe białe światło i szara istota z dużą głową z wielkimi czarnymi oczami wyszeptała mi do ucha – “sprawdź logi Eclipse’a”.
To było to. W katalogu workspace znajdują się metadane Eclipse’a, a między nimi plik .log, będący niemym świadkiem wszystkich Eclipsowych świństw. Wyczyściłem jego zawartość (uprzednio przygotowując kopię zapasową), a następnie zacząłem podglądać na żywo co się w nim dzieje. Uruchomiłem Eclipse i udawałem, że pracuję. Strajkujący od razu naprostowali łamistrajków. Na szczęście pozostał po tym haniebnym zdarzeniu ślad w postaci wyjątku zgłoszonego przez Javę. Winowajcą był plik model.index.db chowający się w katalogu C:\Users\batman\workspace\.metadata\.plugins\org.eclipse.dltk.core.index.sql.h2. Wykonałem kopię zapasową, usunąłem winowajcę i ponownie zbudowałem projekt. Bingo! Eclipse znowu podpowiada składnię! Kolejny raz korporacja pokonała pracujący w pocie czoła lud.
Piąta odsłona PHP została zaprezentowana światu w roku 2004. Zmiany wprowadzone do języka były wręcz rewolucyjne. Programowanie obiektowe w PHP przestało budzić uśmiech politowania, a szereg usprawnień i nowych funkcjonalności robił ogromne wrażenie. Mimo iż od premiery “obiektowego PHP” minęło ponad sześć lat, nadal niektóre – nawet te podstawowe – funkcjonalności pozostają niezrozumiałe i albo kurzą się w zaciszu manuala albo są wykorzystywane w sposób wołający o pomstę do nieba. Taki właśnie los spotkał wyjątki.
Zanim zaczniemy poznawać wyjątki dostępne w ramach SPL, warto wiedzieć po co w ogóle one powstały. Ich powstaniu przyświecał jeden cel – możliwość sterowania przepływem aplikacji w obliczu błędu. A po naszemu – nawet jeśli coś nie zadziała, aplikacja nie wyłoży się koncertowo, tylko będzie próbowała działać w ograniczonym zakresie.
Poza standardową klasą Exception, będącą nadrzędną klasą dla wyjątków, w PHP (a dokładniej w SPL) mamy dostępnych kolejnych trzynaście klas wyjątków. Każda z nich powstała w innym celu.
Wyjątek BadFunctionCallException powstał w celu zasygnalizowania niepopranego wywołania funkcji. Co należy przez to rozumieć? Najprościej będzie to wytłumaczyć na przykładzie.
Kanał ATOM
try {
callMe();
} catch(BadFunctionCallException $e) {
echo $e;
}
function callMe()
{
$args = func_num_args();
if($args < 2) {
throw new BadFunctionCallException('Za mało argumentów');
}
}
BadFunctionCallException można również rzucać w przypadku braku niepoprawnej nazwy funkcji do wywołania.
Obiektowy odpowiednik poprzedniej klasy.
try {
$foo = new Foo();
$foo->niesitniejacaMetoda();
} catch(BadMethodCallException $e) {
echo $e;
}
class Foo
{
public function __call($method, $args)
{
switch($method) {
case 'foo':
/* do magic */
break;
default:
throw new BadMethodCallException('Nie ma takiej metody');
}
}
}
Najmniej zrozumiały i najmniej potrzebny (póki co) wyjątek dostępny w PHP. Wyjątek DomainException powinien zostać zgłoszony w momencie próby skorzystania z danych nienależących do bieżącej domeny. Jak na razie na temat tego wyjątku toczą się akademickie dyskusje, z których można dowiedzieć się, że np. obiekt Foo nie znajduje się w domenie dni tygodnia. W przypadku PHP nie spotkałem się jeszcze z praktycznym zastosowaniem tej klasy.
Wyjątek zgłaszany w momencie otrzymania niespodziewanego/niepoprawnego argumentu.
try {
$foo = new Foo();
$foo->bar('abc');
} catch(InvalidArgumentException $e) {
echo $e;
}
class Foo
{
public function bar($arg)
{
if(!is_numeric($arg)) {
throw new InvalidArgumentException('Niepoprawny argument');
}
}
}
Ten typ wyjątku zgłaszany jest w przypadku odebrania danych o niepoprawnej długości. Niepoprawna długość danych oznacza tutaj nieprawidłowy rozmiar odebranego pliku, błędną ilość danych przesłanych ze strumienia, czy też nieoczekiwaną wielkość tablicy.
try {
$a = array(123, 234, 345);
// z jakiegos powodu tablica musi zawierać dwa elementy
if(count($a) != 2) {
throw new LengthException('Niepoprawna wielkość tablicy');
}
} catch(LengthException $e) {
echo $e;
}
Kolejny klasa wyjątku, z której nie będziemy zbyt często korzystać. Zgłaszany jest w momencie, gdy wyrażenie logiczne oznacza fałsz.
