Co kdyby se E_WARNING převáděly na výjimky?

Krásná myšlenka :-) +1

zrovna při práci se soubory by to bylo určitě velké plus

@vrtak: strict mód převádí i noticky

Editoval paranoiq (15. 7. 2010 20:02)

Strict mode je trošku něco jiného: nevyhazuje výjimku ale natvrdo vyvolá červenou blue-screen v případě čehokoliv. Samotné pojmenování strictMode je trošku zavádějící a vhodnější by bylo $immediateDeath.

jsem proti ;-) asi jediný. ale dokud php nebude mít finally, tak prostě „není“ připravené na výjimky… musí se to pak řešit všemožnými stavovými proměnnými, kod je ještě nepřehlednější… takže! :D za mě -1
ale pokud by to obnášelo, že nette přidá podporu pro finally, tak bych byl určitě pro. :)

hrach napsal(a):

jsem proti ;-) asi jediný. ale dokud php nebude mít finally, tak prostě „není“ připravené na výjimky…

S tím nesouhlasím. Finally je nutnost u jazyků bez garbage collectoru, v případě PHP ho potřebuješ velice výjimečně.

OT ad finally – ukaz jediny priklad, kde je nutne potreba, resp. kde by neco usnadnilo?

Řekl bych, že vnímání finally bude asi trošku špatné :) Jestli to chápu, tak ho chceš používat jako if VSECHNO OK then FINALLY else CATCH…což je samozřejmě špatně, protože finally se provádí vždy, ať už proběhne catch blok nebo ne.

Editoval Ondřej Brejla (15. 7. 2010 21:17)

Tak toto je nonsense – finally se provede VZDY, tj. v pripade chyby se ti vypise „ko“ a pak „ok“ ;)

Finally je pro jazyky, ktere nemaji destruktory – tam je treba delat ruzne stream.close() atp. (tedy cleanup, coz je 99% uziti finally) Php toto ma osetrene paradne, proto zadne finally nepotrebuje.

EDIT: reagoval jsem samozrejme na Hracha

Editoval marek.dusek (15. 7. 2010 21:15)

David Grudl napsal(a):

Pohrávám si v hlavě s trošku revolučním krokem: co kdyby se standardně E_WARNING převáděly na výjimky?

Částečně by to změnilo způsob programování v PHP a uvažování nad kódem (což je zároveň i největší problém). Místo

$handle = fopen('file', 'w');
if (!$handle) ...
fwrite($handle, $s);

by se dalo psát

try {
	fwrite(fopen($handle), $s);
} catch (PHPException $e) {
	...
}

Takze to znamena, ze vsechen normalne napsany kod (ktery kontroluje navratove hodnoty funkci, ktere neco vraci), bude k nicemu, protoze najednou bude hazet vyjimky? Takze se bude muset prepsat?

-1

Krome toho to v uvedenem prikladu nepoznam jestli selhal fwrite nebo fopen. Jo u banalnich CRUD aplikaci, ktere proste kdyz nevi, tak napisou „Internal error“ to asi nevadi. Ale v aplikaci, ktera neco udelat musi, je to dost velky problem.

-1

Implementováno v testovací větvi – otestujte, stahujte

Mne sa to nepáči. Je to príliš veľký zásah do chovania jazyka, resp. nikto takéto správanie neočakáva a je to až priveľký nezvyk. Navyše \PhpException je veľmi zavádzajúce. Stáva sa z toho len limita k Jave, či C#.

minus 1

Takova blbinka, ktera ma imho nulovou pridanou hodnotu, ale nuti predelat vsechen kod – to uz nic jineho k reseni nezbyva? :-)

Editoval marek.dusek (17. 7. 2010 0:02)

bene napsal(a):

Možná jsem blázen ale Notice: Undefined offset… je dle mě chyba a nepřípustná věc. Proto mám zapnutý strict mode.

Mám na ně stejný pohled.

Zajímavá myšlenka, akorát je problém s tou přenositelností kódu. Já opravdu nevím, jestli podpořit nebo odporovat. Ale jako koncept je to opravdu parádní.

Blizzy, myslím že marek.dusek se bavil obecně o koncepci try-catch-finally a tam skutečně platí, že blok finally se provede vždy – ať už se výjimka vyhodí anebo ne.

To že v Nette způsobí redirect ukončení provádění kódu je sice pravda, ale v téhle věci je to irelevantní, protože php blok finally nemá a ani jej nepotřebuje (kvůli již zmíněnému garbage collectoru).

Naprosto korektní mi to přijde takto

try {
        // whatever
        $this->addFlashMessage('Editace se podařila.');
        $this->redirect...
} catch (PHPException $e) {
        $this->addFlashMessage('Editace se nepodařila.');
        $this->redirect...
}

Editoval na1k (17. 7. 2010 23:43)

napsal sem ± blbost, už to tady padlo; nicméně je tu opravdu ten fakt, že pokud použiji cizí knihovnu, která může mít jeden jediný neošetřený warning, už mi spadne aplikace. A teď bych samozřejmě mohl rozjímat nad tím, že daný warning se generuje jen při určitém vstupu, který nejsem schopen zjistit vlastním testováním… nebezpečí hrozí takhle víc, než se zdá…

Editoval hrach (18. 7. 2010 11:13)

David Grudl napsal(a):

Takze to znamena, ze vsechen normalne napsany kod (ktery kontroluje navratove hodnoty funkci, ktere neco vraci), bude k nicemu, protoze najednou bude hazet vyjimky? Takze se bude muset prepsat?

Nikoliv, pokud si teda pod pojmem „normalne napsany kod“ představujeme kód, který nevyhazuje warningy.

Takze to znamena, ze aby nette nehodilo vyjimku, tak pred vsema funkcema, ktere muzou generovat warning musi byt zavinace?

odin napsal(a):

Takze to znamena, ze aby nette nehodilo vyjimku, tak pred vsema funkcema, ktere muzou generovat warning musi byt zavinace?

Uzavíráš funkce, které mohou generovat výjimky, do prázdného try { } catch()?

David Grudl napsal(a):

odin napsal(a):

Takze to znamena, ze aby nette nehodilo vyjimku, tak pred vsema funkcema, ktere muzou generovat warning musi byt zavinace?

Uzavíráš funkce, které mohou generovat výjimky, do prázdného try { } catch()?

ne to rozhodne ne, to bych tu chybu ignoroval ;) Ale jsou funkce, ktere vraci chybovou hodnotu a vyhazuji warning, cili modelovy priklad:

<?php
if (!mysql_connect('foobar', 'foo', 'bar')) { //zde warning
	....
	//nejake osetreni chyby. Pokud potrebuju, hlasku si vezmu z get_last_error() nebo mysql_error() nebo neco takovyho
} else {
	mysql_select_db('treba')
}
?>

Takze aby to ted prolezlo, tak musim pred mysql_connect napsat @ (i kdyz testuji navratovou hodnotu (a warning nevypisuju), treba tak, jak je to v Dibi (ale toto se pochopitelne netyka jen DB funkci, zeano).

Nebo z opacne strany – problem vidim v tom, ze warning v PHP znamena ledacos – jak runtime potize (treba, ze nejede DB), tak problemy v kodu (nespravny pocet parametru pro funkci). To druhe by si jiste prevod na PHPException zaslouzilo.

David Grudl napsal(a):

Honza Kuchař napsal(a):

Zajímavá myšlenka, akorát je problém s tou přenositelností kódu. Já opravdu nevím, jestli podpořit nebo odporovat. Ale jako koncept je to opravdu parádní.

Asi jediná možnost je to zkusit nějakou dobu používat a pak se rozhodnout. Na měsíc to zkusím a uvidím.

Teď, když si čtu znova, jak by to fungovalo, jsem pro. Protože pokud tam, kde byl doteď zavináč a kontroluje se návratová hodnota, to bude fungovat i nadále, je to zpětně kompatibilní. Pokud to vyhodilo WARNING, je to zásadní chyba → výjimka je adekvátní. Geniální. :) Doufám, že jsem pochopil správně funkci.

Tedy potřeba si uvědomit, že jakýkoli kód, který předpokládá, že warningy budou potlačeny je špatný. Tedy za mě tento nápad i realizace má ZELENOU. Zvýší to jednoznačně kvalitu kódu.

Nicméně – před lety byl i koncept třídy Debug, která všechny E_NOTICE buď zobrazuje nebo loguje, podobně utopistický. Srovnej třeba s patičkou na stránkách http://php.vrana.cz/ ;)

Jak píšeš. :)

Ondřej Mirtes napsal(a):

Na jednu stranu je to zajímavý nápad, na druhou stranu je to magie. Magie, která činí kód nepřenositelným. Nechci se ve svých třídách spoléhat na to, že poběží v prostředí Nette. (Konkrétně, že budou někam includovány po zavolání Debug::enable(), který asi toto chování spustí.)

Je to velký zásah do chování jazyka. Jako proof-of-concept pěkné, ale do ostré verze tomu nejspíš podporu nevyjádřím.

Suhlasim, myslienka je to pekna, ale ak by si clovek pisal veci obecne a potom chcel nejaku malu cast nasadit aj mimo prostredia Nette tak by mal problem.

bene napsal(a):

A nešlo by, aby se strict mode choval tak, že bude vyhazovat výjimky? A přidat $immediateDeath jako aktuální chování strict mode?

Možná jsem blázen ale Notice: Undefined offset… je dle mě chyba a nepřípustná věc. Proto mám zapnutý strict mode.

+1 .. to immediateDeath je pekny napad

odin napsal(a):

ne to rozhodne ne, to bych tu chybu ignoroval ;) Ale jsou funkce, ktere vraci chybovou hodnotu a vyhazuji warning, cili modelovy priklad:
<?php
if (!mysql_connect(‚foobar‘, ‚foo‘, ‚bar‘)) { //zde warning

Mám za to, že programátoři v Nette se snažím podobným warningům automaticky předcházet a tedy rovnou použijí zavináč (což by potlačilo i vyhození PhpException) a poté kontrolují návratovou hodnotu. V tomto směru by se tedy nic nezměnilo.

Naopak by ale vznikla možnost psát kód takto:

try {
	mysql_connect('foobar', 'foo', 'bar');
	mysql_set_charset('utf8');
	mysql_select_db('xxx');
} catch (PhpException $e) {
	// nejake osetreni chyby
}

(ano, je to „nový jazyk“)

Mnohem zajímavější je to v kombinaci se skládáním funkcí:

try {
	$product = mysql_fetch_assoc(mysql_query('SELECT * FROM products WHERE id=123'));
} catch (PhpException $e) {
	...
}

try {
	$items = $link->query('SELECT * FROM products')->fetch_all(); // tohle je modelový příklad, mysqli umí vyhazovat mysqli_sql_exception
} catch (PhpException $e) {
	...
}

David Grudl napsal(a):
Mám za to, že programátoři v Nette se snažím podobným warningům automaticky předcházet a tedy rovnou použijí zavináč (což by potlačilo i vyhození PhpException) a poté kontrolují návratovou hodnotu. V tomto směru by se tedy nic nezměnilo.

No to je presne to co jsem psal na zacatku. Cili, aby ten kod (dejme tomu kod nejake knihovny) fungoval stejne, tak je potreba pred vsechny funkce, ktere muzou hodit warning dat zavinace (anebo tuhle ficuru vypnout). Proc to tak rozebiram – jsou funkce, ktere warning generuji jen za dobreho pocasi – napr mysql_select_db() – pokud DB neexistuje vrati false, pokud je chyba ve spojeni v DB vrati false a generuje warning. mysql_query() se chova tusim podobne. Coz vede na to, ze treba hodne lidi pise @mysql_connect(), to je ok, ale uz ne @mysql_select_db() protoze to zkratka vetsinou warning negeneruje. Kdo treba pise zavinace pred preg_replace()? ftp_chmod() se myslim chova taky tak nejak podobne debilne.

Problem proste vidim v tom, ze ty warningy jsou pomichane dohromady veci co by mely byt LogicException a RuntimeException a notice. Cili vezmu aplikaci – na test serveru jede, dam na produkcni a prask vyjimka a mrtvo (prestoze by se z toho ta aplikace klidne zvetila). Resp. ve svym kodu si to muzu pohlidat, problem je s knihovnama.

Naopak by ale vznikla možnost psát kód takto:

try {
	mysql_connect('foobar', 'foo', 'bar');
	mysql_set_charset('utf8');
	mysql_select_db('xxx');
} catch (PhpException $e) {
	// nejake osetreni chyby
}

Jasne, to chapu, to je to super. Konecne to PHP vypada jako normalni jazyk.

odin napsal(a):

…jsou funkce, ktere warning generuji jen za dobreho pocasi – napr mysql_select_db() – pokud DB neexistuje vrati false, pokud je chyba ve spojeni v DB vrati false a generuje warning.

A ruku na srdce, nejsou to právě situace, kdy by výjimka zachránila víc, než opomenutý test návratové hodnoty?

Teoreticky by šlo chování povolovat jen pro některé třídy nebo soubory pomocí anotací.