az átkozott die. Avagy le tudom-e lőni a php scriptet igazából és miért hülyül meg leállásnál
most találkoztam a problémával. Eddig abban a hitben éltem, hogy a die abban különbözik az exit-től, hogy kilövi a php-t abban a pillanatban, amikor meghívom, és kész. Megkockáztatom, hogy php3 környékén így volt még, csak én nem frissítem a tudásomat a megszokott függvényeknél.
A PHP oldal szerint korrekten: alias ax exit()-re.
Szóval.
1. Ki tudom-e lőni a php-t úgy, hogy "Álljál le! most!"?. Na nem olyan megoldásokkal, hogy írok egy progit, ami megkeresi a pid-jét és nekivág egy SIGKILL-t, hanem úgy szépen, magából a kódból. Szerintem nem.
2. Miért hülyül meg?
Esettanulmány:
Intro:
Van egy User objektumom. Van egy NoSuchUser és egy SQLQuery Exceptionom. Van egy Errorhandlerem.
A User objektum vár egy userid-t konstruktorba, majd betölt, és a script futása alatt szépen tesz-vesz a memóriában, a destruktálásnál pedig mindent, amit tett-vett visszaírja az adatbázisba.
A Helyzet:
Létrehozok egy user objektumot egy nemlétező userid-vel. Erre eldob egy NoSuchUser Exceptiont. Ezt az errorhandler, mivel nem igazán tudja kijavítani leloggolja, majd azt mondja :die
De a die nem die, hanem becsülettel végighívogatja mindennek a destruktorát, igy a User-ét is. A user destruktora megpróbálja lementeni az adatbázisba a nemlétező User cuccait, hát de mivel nemlétező és ezértazért, dob egy SQLQuery Exceptiont. Beindul az autoloader, és keresi a file-t az SQLQueryException-nek.
De nem találja.
Ha die előtt jön megvan a file, ha die után jön, akkor bizony nincs meg egy file sem. Relatívhivatkozással, is_file(...)-lal.
Láttatok már ilyet??
tz
■ A PHP oldal szerint korrekten: alias ax exit()-re.
Szóval.
1. Ki tudom-e lőni a php-t úgy, hogy "Álljál le! most!"?. Na nem olyan megoldásokkal, hogy írok egy progit, ami megkeresi a pid-jét és nekivág egy SIGKILL-t, hanem úgy szépen, magából a kódból. Szerintem nem.
2. Miért hülyül meg?
Esettanulmány:
Intro:
Van egy User objektumom. Van egy NoSuchUser és egy SQLQuery Exceptionom. Van egy Errorhandlerem.
A User objektum vár egy userid-t konstruktorba, majd betölt, és a script futása alatt szépen tesz-vesz a memóriában, a destruktálásnál pedig mindent, amit tett-vett visszaírja az adatbázisba.
A Helyzet:
Létrehozok egy user objektumot egy nemlétező userid-vel. Erre eldob egy NoSuchUser Exceptiont. Ezt az errorhandler, mivel nem igazán tudja kijavítani leloggolja, majd azt mondja :die
De a die nem die, hanem becsülettel végighívogatja mindennek a destruktorát, igy a User-ét is. A user destruktora megpróbálja lementeni az adatbázisba a nemlétező User cuccait, hát de mivel nemlétező és ezértazért, dob egy SQLQuery Exceptiont. Beindul az autoloader, és keresi a file-t az SQLQueryException-nek.
De nem találja.
Ha die előtt jön megvan a file, ha die után jön, akkor bizony nincs meg egy file sem. Relatívhivatkozással, is_file(...)-lal.
Láttatok már ilyet??
tz
PEAR?
die
működik rosszul. Egy shutdown functionben kiadott exit hatására viszont ténylegesen megáll a működés.Felhő
register_shutdown_function().
A register_shutdown_function() még php4-ben volt egy amolyan workaroung a destruktotok helyett, bár gondolom a probléma teljesen analóg azzal, amit írsz. :)
Szemlélet...
pont ezt csinálja
Felhő
Nem érted...
nem érted
Aztán meg a webes OOP ott kezdődik, hogy csücsül mögötted egy alkalmazásszerver :)
elmélet vs gyakorlat
Ami ugye PHP esetén automatikusan megtörténik a legtöbb esetben. Ezért hadd legyen a programozó felelőssége, hogy eldönthesse, hogy használ-e bármilyen olyan dolgot, ami kifejezetten szükségessé teszi a destruktor meghívását, főleg egy olyan használati esetben, amikor a program zátonyra futott.
Felhő
Megint nem érted.
adatbázis tervezés, tranzakció kezelés
Amúgy meg kifejezetten kiemeltem a fejlesztő felelősségét.
Felhő
lokkolás
Biztonságkritikus rendszereknél elkerülhetetlen.
Mondok egy példát
generálni akarsz egy nagy szórású egyedi id-t, megkockáztatom, ezt kb így csinálja mindenki:
--
id <- valamirandomrandom
amig létezik az adatbázisban ez az id:
... id <- valamirandomrandom
megvan, beleírom az adatbázisba
--
ebben az esetben simán előfordulha, hogy 2 script egyszerre fut le, és ugyanazt az id-t generálja, mert az első éppen a ciklusmagban van, mikor a
második éppen a ciklusfeltételnél.
Erre mondjál más megoldást lockolás nélkül, nem hiszem, hogy van, kiváncsi vagyok.
unique index vagy szekvencia
Bár ha kifejezetten azonosítóra van szükség, akkor használhatsz szekvenciákat is. Vagy ha pl. egy index fa telítettségét szeretnéd ezzel a random cuccal segíteni, akkor pl. ezt a szekvenciát teheted a végére, vagy pl. megcserélsz benne egy részt, ezáltal nem lesz monoton növekvő.
Felhő
unique index
Meggyőztél. :)
Miért ne értené?
Ha egy objektum példányosítás során a konstruktor nem fut le, mert az exception a konstruktorban keletkezik, akkor miért is hívódik meg a destruktora? Ez azért nem helyes. Ha nincsen példány akkor nincsen mire meghívni a destruktort, nem? Ezen esetben pedig az exception kezelés helyén a konstruktorban kell a kontruktorban megnyitott erőforrásokat bezárni és nem a destruktorban.
Egyébként miért kell mindenkit OOP nullának nézni ? :)
(Ja bocs hogy beleszóltam csak egy közös projektünkben jött elő a dolog)
ez az
Ha házat építek, és az első percben eltörik az ásó, akkor nem lesz ház. Hülyeség azt mondani, hogy na akkor ezt a házat most jól leromboljuk :)
A PHPben meg lesz ház. Ha elszáll a konstruktor, lesz objektum, csak nem lesznek kitöltve a változói :(
Jól van...
Ha lerakod az alap felét és utána törik el az ásó akkor vissza is kell szedni az alap felét, nincs mese.
inkább: ez van
tényleg túlragoztuk a témát, viszont:
most akkor ezt így ki lehet jelenteni, hogy a destruktor PHP-ben "ha kell, ha nem" meghívódik? nagy tanulság...
Tasi
túlragozzuk
valami hasonló dolog
Felhő
Nem akartam
Akkor végül ilyen utasítás nincsen?
Bár a lényeg inkább az, hogy hogy megy ez? die közbeni függvényeknél meghal az filekezelés? Láttatok már ilyet?