[PHP] Gebruik van @ bij session_start()

[Verwijderd]

Waarom zie je bij de ene site @session_start() staan en bij de andere site weer session_start()
Dus met of zonder @.
Waar dient dit voor, wanneer gebruik ik het of juist niet?

Ik kan het bv. nergens vinden op php.net

Grx,
Joris

[Verwijderd]

De @ voor een functieaanroep onderdrukt eventuele foutmeldingen.

[Grimli]

De @ is om error meldingen te onderdrukken. session_start mag je alleen gebruiken als er nog geen headers zijn verzonden.

Ik vermoed dat de sites waar jij de @ ziet staan, dat stiekum wel doen. Dat is natuurlijk niet helemaal de bedoeling, hoewel het waarschijnlijk wel zal werken .

[ACM]

't Is dus eigenlijk slordige code, als je denkt het nodig te hebben om die aanroep te onderdrukken. Want het duidt eigenlijk altijd op een fout in de code elders als blijkt dat er foutmeldingen uit session_start (en andere functies) rollen.

Desondanks is het niet perse helemaal fout om die @ te plaatsen, want het voorkomt dat gebruikers de foutmeldingen te zien krijgen. Toch kan je dat, imho, dan beter oplossen door de error_reporting te veranderen zodat er minder meldingen getoond worden aan het begin van je code en als je in debug-mode bezig bent die error_reporting juist zodat er meer meldingen tevoorschijn komen.

[drm]

Het volgende zou overigens mijn voorkeur genieten: de directive display_errors op off, i.c.m. een custom errorhandler en de error reporting toch gewoon op E_ALL zetten

[Verwijderd]

ACM schreef op 13 oktober 2004 @ 12:43:
't Is dus eigenlijk slordige code, als je denkt het nodig te hebben om die aanroep te onderdrukken. Want het duidt eigenlijk altijd op een fout in de code elders als blijkt dat er foutmeldingen uit session_start (en andere functies) rollen.

Desondanks is het niet perse helemaal fout om die @ te plaatsen, want het voorkomt dat gebruikers de foutmeldingen te zien krijgen. Toch kan je dat, imho, dan beter oplossen door de error_reporting te veranderen zodat er minder meldingen getoond worden aan het begin van je code en als je in debug-mode bezig bent die error_reporting juist zodat er meer meldingen tevoorschijn komen.

Ik gebruik juist graag de "@", ik vang foutmeldingen, zoals drm zegt, liever zelf op dan dat PHP de applicatie eruit knalt met een error. Er zit dan ook een verschil in een "@" gebruiken en misbruiken.

[Janoz]

Hoezo? Bij een error wordt er sowieso uitgeklapt. En de warnings kun je gewoon mbf settings uitzetten. Ideaal voor als je een keer gaat debuggen. Dan zet je de level gewoon weer wat hoger. @'s gebruiken vind ik persoonlijk een luie en lakse oplossing en code waarin ik dit zie neem ik een stuk minder serieus.

[Verwijderd]

Janoz schreef op 13 oktober 2004 @ 14:20:
Hoezo? Bij een error wordt er sowieso uitgeklapt.

Wel eens met plaatjes aan de slag gegaan?

imagecreatefromjpeg() returns an empty string on failure. It also outputs an error message, which unfortunately displays as a broken link in a browser.

Dat vang ik liever op met een "@" dan dat ik zo'n gore php melding in beeld krijg.

[ACM]

Nou... je kan er natuurlijk ook voor zorgen dat je de fout niet krijgt, maar dat is in dit specifieke voorbeeld wel wat lastig. Dingen als fopen's die roepen dat ze specifieke files niet kunnen vinden kan je gewoon oplossen door een file_exists-call voor die fopen te plaatsen.

Corrupte plaatjes, die wel bestaan, maar toch imagecreatefromjpeg laten falen is inderdaad wat andere koek. Imho is het wat slordig dat het die dingen zo maar afschiet, gelukkig zijn ze nu begonnen met exceptions. Laten we hopen dat die ook uit php-functies gaan rollen in de nabije toekomst, zodat je zoiets kan doen:

PHP:

try
{
... =   imagecreatefromjpeg(...);
}catch(CorruptImageException $cie)
{
  ....
}

En dat je dan mooi onderscheid kan maken tussen allerlei typen fouten, zonder te klooien met stringmanipulatie, onderdrukking van foutmeldingen en het wijzigen van error-levels.
Maar dat zal nog wel even duren voor dat dat gebeurt, als het al ooit gebeurt.

[Verwijderd]

Janoz schreef op 13 oktober 2004 @ 14:20:
Hoezo? Bij een error wordt er sowieso uitgeklapt. En de warnings kun je gewoon mbf settings uitzetten. Ideaal voor als je een keer gaat debuggen. Dan zet je de level gewoon weer wat hoger. @'s gebruiken vind ik persoonlijk een luie en lakse oplossing en code waarin ik dit zie neem ik een stuk minder serieus.

Vind ik eingelijk niet geheel, er zijn inderdaad oplossingen te bedenken om fouten op te lossen of zo veel controles te doen om een fout dan ook maar enigsinds te voorkomen.

Ach als het een klein projectje is, waarom moeilijk doen als het makkelijk en laks kan

[Verwijderd]

ACM schreef op 13 oktober 2004 @ 17:55:
Dingen als fopen's die roepen dat ze specifieke files niet kunnen vinden kan je gewoon oplossen door een file_exists-call voor die fopen te plaatsen.

Ja maar die werkt weer niet met remote files en is_file() ook niet.

ACM schreef op 13 oktober 2004 @ 17:55:
...Laten we hopen dat die ook uit php-functies gaan rollen in de nabije toekomst, zodat je zoiets kan doen:

Ja dat zou mooi zijn, alleen is het eigenlijk ook ondrukken van een foutmelding.

[Janoz]

Het vangen van een exception is in de verste verte niet te vergelijken met het onderdrukken van een foutmelding. Slechts waneer je het catch onderdeel leeg laat zou het hetzelfde kunnen zijn. Door de try catch structuur geef je juist extra aan dat daar die fout op die manier afgehandeld dient te worden.

[Verwijderd]

Janoz schreef op 14 oktober 2004 @ 09:41:
Het vangen van een exception is in de verste verte niet te vergelijken met het onderdrukken van een foutmelding. Slechts waneer je het catch onderdeel leeg laat zou het hetzelfde kunnen zijn. Door de try catch structuur geef je juist extra aan dat daar die fout op die manier afgehandeld dient te worden.

Ik begrijp dat het niet hetzelfde is, ik zet er niet voor niets een " " bij...

Feit blijft, dat of je nu een "@" plaatst of je gebruikt try-catch, je bent met foutafhandeling bezig, omdat je op die plaats een fout verwacht en je wilt dat er op een bepaalde manier op gereageerd wordt. Met php kan je het vaak niet op een mooie manier als try-catch oplossen, dus plaats je in zulke gevallen een "@". Dat is wat ik bedoelde met gebruiken en misbruiken.

Ben met je eens, als er in een script allerlei kunstgrepen zijn toegepast om de werking te forceren (zoals wellicht bij @ sessionstart()), je vraagtekens kan plaatsen bij de schrijver van het script.

Maar ik geloof dat de vraag van de TS inmiddels ruimschoots beantwoord is..