Tak na prawdę wg mojej skromnej opinii wyjątek potrafi być przydatny w 3 miejscach.
1. Gdy łączę się z zewnętrznym serwerem. Jeżeli mam całą procedurę obejmującą autoryzację użytkownika logującego się do drugiego serwera itp to wolę napisać to z marszu bez komplikacji i przerwać jak się coś wysypie.
2. Gdy bawię się z plikami. Ta sama sytuacja. Gdy mam krótką procedurę która ma coś zrobić z plikiem to chcę ją przerwać gdy coś pójdzie nie tak a nie opisywać się tonami warunków.
3. Baza danych. Wiadomo.
To taka podstawka.
]]>Ad. końcowego akapitu -> ano właśnie, piszesz z jednej strony, że powinno się o tym zacząć myśleć już w czasie PHP3, a z drugiej wybaczasz mi „moje” potknięcia, gdzie pracuję de facto sam. To teraz fakt z historii PHP: jądro PHP3 stworzyły dwie osoby, zanim pokazały efekty istniejącej społeczności. Te dwie osoby były studentami. I zrobiły to w ramach projektu uczelnianego, ucząc się na własnych błędach. Przypuszczam, że gdybym to ja się brał za napisanie interpretera czegoś na kształt PHP, również przepisałbym wszystko 3, 4 razy, zanim zrobiłbym to tak, jak należy nawet mimo tego, że wiem dokładnie, co chcę osiągnąć.
A skoro wspomniałeś o większej liczbie pomysłów do rozważenia, to masz tu właśnie konsekwencje jednego z wymienionych punktów: ktoś musi te pomysły przeglądać, ktoś musi je zaplanować, przedyskutować itd. co jest tym trudniejsze, im więcej jest osób w zespole. I stąd trwa to tak długo i robione jest stopniowo, bo wszystkiego naraz się nie da, chyba że piszemy projekt całkowicie od zera.
]]>Moim zdaniem przypadek niestandardowy, ale niedługo może się on wraz z coraz częstszym upowszechnianiem frameworkow i obsługi błędów innej niż serwerowe komunikaty i zwykłe headery, upowszechnić. Niestety ale po otrzymaniu zamiast bool(false) czegoś w stylu:
array(10) { [„wrapper_data”]=> array(2) { [„headers”]=> array(0) { } [„readbuf”]=> resource(4) of type (stream) } [„wrapper_type”]=> string(4) „cURL” [„stream_type”]=> string(4) „cURL” [„mode”]=> string(2) „rb” [„unread_bytes”]=> int(0) [„seekable”]=> bool(false) [„uri”]=> string(59) „uri_do_nieistniejącego_pliku” [„timed_out”]=> bool(false) [„blocked”]=> bool(true) [„eof”]=> bool(false) }
fopen nie zrozumie, że ma do czynienia z nieistniejącym zasobem
Na pierwsze pytanie odpowiem Ci następująco: jakbyś Ty był szefem projektu, bałbym się z Tobą pracować przy takim podejściu – tylko czekać, aż byś przyszedł z tekstem “masz tu 5 ludzi do pomocy i przepisz mi jądro Linuksa na za tydzień” :).
Hmm, masz rację, pożerałbym ludzi z ekipy żywcem i zmuszał do samodzielnego wytwarzania prądu na rowerkach. Ale nie musiałeś psuć mi niespodzianki.
2. “podwojenie ilości osób nie oznacza skrócenia o połowę czasu wykonania zadania” – narzut na komunikację, organizację, zarządzanie, projektowanie… jest to jedna z pierwszych rzeczy, jakiej uczą człowieka na studiach informatycznych w zakresie projektowania aplikacji.
Absolutnie się z Tobą zgadzam, ale jest pewne ale, mianowicie: projektowanie architektury systemu. Niestety, jest to dość często zaniedbywane, potem konsekwencje uderzają ze zdwojoną siłą. A mam wrażenie, że w przypadku PHP rozplanowania po prostu zabrakło.
Porządne planowanie powinno się zacząć już na etapie PHP3, kiedy to jakiekolwiek zmiany nie były jeszcze aż tak bolesne, jak zmiana funkcjonalności obecnie, sam zresztą znasz historię. Teraz, to hmm…
“mogłem po prostu od początku ten element zrobić tak, jak ma być, zamiast teraz się męczyć z przerabianiem i zapewnianiem kompatybilności”. Mimo iż też mnie to denerwuje, rozumiem ich trochę, ponieważ sam znalazłem się w takiej sytuacji niejednokrotnie.
Owszem, ale nad OPT działała tylko Twoj geniusz, a nad PHP nieco więcej – czyli więcej pomysłów było do rozważenia – przyjęcia bądź eliminacji. Zresztą, odrobiłeś pracę domową w postaci przeanalizowania innych systemów szablonów, a jeśli chodzi o twórców PHP w porównaniu z innymi językami – po prostu tego nie zrobili… Ale należy im podziękować choćby za użycie składni i niektórych nazw z C, a nie wciskania na siłę niecodziennej składni jak w Erlangu (mój zeszłoroczny pierwszy raz był… uhm… konsernacją?).
]]>1. kod źródłowy PHP też jest duży (800 tys. linijek kodu + takie rzeczy, jak opis gramatyki, które mogą nie być liczone)
2. „podwojenie ilości osób nie oznacza skrócenia o połowę czasu wykonania zadania” – narzut na komunikację, organizację, zarządzanie, projektowanie… jest to jedna z pierwszych rzeczy, jakiej uczą człowieka na studiach informatycznych w zakresie projektowania aplikacji.
3. te kilkadziesiąt osób ma na głowie jeszcze 100 innych rzeczy, niż tylko „Twoje” (i moje w sumie też) wyjątki.
Na drugie pytanie nie mam odpowiedzi – pytaj się ich. Też bym chętnie ją poznał, natomiast mogę tylko snuć przypuszczenia. Równie dobrze możesz się mnie pytać, czemu np. ja w OPT coś implementuję dopiero teraz, kiedy „mogłem po prostu od początku ten element zrobić tak, jak ma być, zamiast teraz się męczyć z przerabianiem i zapewnianiem kompatybilności”. Mimo iż też mnie to denerwuje, rozumiem ich trochę, ponieważ sam znalazłem się w takiej sytuacji niejednokrotnie.
]]>Tak btw. error exception ma w sobie np taką właściwość jak ’severity’ która mówi jaki typ błędu (NOTICE,FATAL etc)
Ok, otwierasz plik i skąd wiesz, czy to był błąd braku uprawnień, czy może nie istniejącego obiektu? E_WARNING coś mówi? Nie sądzę. Chyba że masz lepsze fusy od moich, to wtedy się zgodzę.
]]>