Door
Ozzie PHP
op 25-11-2013 11:41
gewijzigd op 25-11-2013 11:49
6.556 views
Ola,
Als er in mijn applicatie iets fout gaat, dan wil ik daar een error-level aan kunnen koppelen.
Zelf dacht ik om gebruik te gaan maken van 3 gradaties:
1) notice: een kleine fout, bijv. een user vult een getal in in plaats van een string
2) warning: een serieuze fout, bijv. een file kan niet worden opgeslagen
3) error: er gaat iets goed mis, bijv. er kan geen database-verbinding tot stand komen
Een notice zou ik dan alleen loggen in een log-bestand. Een warning zou ik zowel loggen als mailen, en bij een error zou ik loggen en mailen en de rest van de applicatie stoppen.
Zijn deze 3 gradaties toereikend volgens jullie? Of zijn er nog tussenstappen te bedenken, en zo ja welke?
- 1) Merk ten eerste op: als er 1 parse error in je .php bestand staat, wordt het hele bestand niet uitgevoerd. Dus dat kan je moeilijk echt opvangen.
- 2) Dan zijn er fouten die een IDE kan vinden. bv. je roept een functie op; die functie is nergens te vinden. Hiervoor moet je php niet uitvoeren om de fout te vinden.
- 3) Runtime errors:
* Stel: je krijgt op basis van een ajax-request een functienaam mee. Bij het uitvoeren van het Ajax-verzoek moet je die functie dan uitvoeren.
Indien je een foute naam krijgt, kan je die functie niet uitvoeren (wegens onbestaande).
Het punt is: de fout ontstaat pas nadat het script is beginnen runnen
* bv. fetchen van een $res die afkomstig is van een mysql_query die false teruggeeft ... Een parser of een IDE kan onmogelijk op voorhand weten dat die $res false zal zijn. Dat weet je slechts in runtime
Als je er in slaagt de twee laatste uit mekaar te halen, zeker doen.
-----
Het punt is vooral: Error 2) zou je eigenlijk nooit mogen voor hebben; tenzij wanneer je aan het schrijven bent.
Runtime errors zijn errors die je in de loop van het gebruik kan merken. Als de website niet grondig getest is, kan je, misschien maanden later, pas voor het eerst die fout zien.
Kris, dankjewel voor je reactie. Het gaat mij juist om exceptions die je zelf kunt opvangen. Stel dat ik een bestand wil opslaan. Dan doe ik een try en catch. Op het moment dat het bestand niet kan worden opgeslagen, dan wil ik dat er actie wordt ondernomen. De gradatie die hier volgens mij bij hoort is een WARNING (zie mijn eerste bericht). Ik zou dan loggen en (naar mezelf) mailen dat een bestand niet kan worden opgeslagen.
Behalve een WARNING zou ik dan denken aan een NOTICE en een ERROR (zie voor de omschrijving weer mijn eerste bericht). Mijn vraag is of je nog meer levels nodig hebt, of dat dit de lading dekt.
Een error stopt het script.
Een warning stopt het script niet. (maar waarschijnlijk zal de gebruiker content ontbreken door de warning)
Een notice betekent zo goed als niets in mijn ogen. Het verandert meestal niets aan de logica.
---
Sowieso, als je voorzichtig bent, krijg je geen errors.
Dat vergt wel extra if's, soms diep genest.
Maar jij suggereert om zelf exceptions op te roepen.
Dat is meer de Java aanpak. Mensen met een C verleden, zullen dat waarschijnlijk wat minder doen.
Mij geen probleem hoor.
Dat is een lastige redenering, want als je die lijn doortrekt, zou je alles afhankelijk moeten maken van de huidige instelling van error_reporting() en bij exceptions moeten terugvallen op de Standard PHP Library (SPL).
Bij een OOP framework kun je, denk ik, beter het advies van Dos volgen en de LoggerInterface implementeren. Die logt ook meer dan alleen fouten, waaronder "interesting events" zoals een gebruiker die inlogt, en heeft een apart level voor debugging. Heb je dat ook meteen meegenomen.
>> waaronder "interesting events" zoals een gebruiker die inlogt
Dit kan inderdaad interessant zijn, maar heeft verder niets met error handling te maken. Ik wil graag weten hoeveel gradaties er zijn waarin je zelf fouten kunt afhandelen. Volgens mij zijn dat er maar 3:
notice - er gaat iets kleins mis, bijv. een user die verkeerde input invoert
warning - er gaat serieus iets mis wat aandacht nodig heeft, bijv. een bestand dat niet kan worden opgeslagen
error - foute boel, er gaat iets dusdanig mis dat de applicatie gestopt moet worden, bijv. een database die geen connectie kan maken
Ik zou denken dat dit alles is, maar wellicht zie ik iets over het hoofd?
>> en heeft een apart level voor debugging
Wat kun je hier eigenlijk mee. Waar heb je dit voor nodig?
Als je exceptions afvangt, zijn drie niveaus niet toereikend. Je hebt dan niet slechts "een error", maar bijvoorbeeld ook een catchable runtime error. Neem een cURL-verbinding die upstream ergens data vandaan haalt: die kan een error (server onbereikbaar) keren in een warning wanneer je terug kunt vallen op een lokale cache. In een log wil je daarvoor twee items op een ander niveau terugvinden: het falen van de cURL-verbinding en aansluitend het gemopper van de klasse die de verbinding gebruikte.
Debuggen kun je zo simpel of uitgebreid maken als je zelf wilt. Bij exceptions is vooral Exception::getTrace() belangrijk: hieruit kun je aflezen welke route exceptions hebben afgelegd door je applicatie. De LoggerInterface leent zich ook voor het loggen van dit soort debugmeldingen. Vandaar dat ik het advies van Dos zou volgen: implementeer de LoggerInterface, want dan ben je meteen klaar en hoef je niet later het wiel opnieuw uit te vinden.
>> Als je exceptions... die de verbinding gebruikte.
Oké, maar op het moment dat je applicatie door kan gaan dan is het dus een WARNING (iets wat aandacht behoeft, maar de applicatie hoeft niet te stoppen).
Wat betreft het debuggen. Ik begrijp niet WANNEER je een debug-actie wilt loggen. Als er iets fout gaat wil je toch altijd debug informatie hebben?
