hoeveel error-levels?
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?
Gewijzigd op 25/11/2013 11:49:42 door Ozzie PHP
Zorg dat alle 8 levels beschikbaar zijn. Hoeveel je er daadwerkelijk gebruikt is een ander verhaal. Das is namelijk jouw keuze.
- 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.
Gewijzigd op 25/11/2013 12:07:46 door Kris Peeters
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.
Euh, het is toch goed om exceptions te gebruiken?
Kris Peeters op 25/11/2013 13:05:06:
Ik zou de redenering van php volgen.
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.
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?
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.
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?
Ozzie PHP op 25/11/2013 14:27:35:
>> 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).
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).
Niet als je OOP programmeert. De cURL-klasse weet dan niet waarvoor zij wordt gebruikt en hoort dat ook niet te weten. Die klasse kan dus geen onderscheid maken tussen een warning en een notice. Pas de andere klasse maakt daarvan een notice als deze het probleem in een catch omzeilt.
Ozzie PHP op 25/11/2013 14:27:35:
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?
Meestal wil je dat natuurlijk op je scherm zien. Maar er zijn situaties waarin loggen beter is. Straks laat je bijvoorbeeld testgebruikers los op een bèta. Je gaat dan niet zitten wachten op hun bugreports, maar logt de bugs.
Als je met twee schermen werkt, kun je sneller debuggen door de log live naast de applicatie te tonen. Dat is makkelijker dan in het onderwaterscherm van een HTML-pagina naar foutmeldingen gaan zitten zoeken.
En wat denk je van user handelingen? Ik zou graag willen loggen welke acties een moderator doet, zodat die bij gehouden kunnen worden.
Voor het loggen heb je dus nog veel meer informatie om te loggen, daarom heb je ook meer levels nodig. En dan zal ik altijd de psr standarden volgen.
Dit is ook wat ik bedoel. Ik wil een exception opvangen en afhankelijk van de aard (gradatie) van de exception wil ik die exceptnio bijv. loggen en mailen. Dit wil ik laten doen door een handler. Door de juiste error mee te geven, moet die handler dan loggen, mailen of in het uiterste geval de applicatie stoppen.
Wat betreft debuggen... ik snap dat je niet wilt dat gebruikers debug-informatie zien. Ik snap niet waarom debug een log-level is. Het is toch helemaal geen level? Ieder "level" kun je zelf voorzien van debug-informatie dus ik snap het nut niet zo goed.
@Wouter:
Ik snap wat je bedoelt met het verschil tussen error en log levels. Goed dat je dat onderscheid maakt. Mij gaat het het dus om de error levels. Jij zegt:
"Een error is slechts een fatal, error, notice of warning"
Volgens jou zijn het er dan 4? Wat is precies het verschil tussen fatal en error?
Ozzie PHP op 25/11/2013 15:20:04:
Dit is ook wat ik bedoel. Ik wil een exception opvangen en afhankelijk van de aard (gradatie) van de exception wil ik die exceptnio bijv. loggen en mailen. Dit wil ik laten doen door een handler. Door de juiste error mee te geven, moet die handler dan loggen, mailen of in het uiterste geval de applicatie stoppen.
De logger logt. Laat je de logger meer doen, dan leg je te veel verantwoordelijkheid bij de logger. De logger moet bij mijn voorbeeld weten dat het ene gebruik van de cURL-klasse mag eindigen in een notice en het andere gebruik in een warning. Daarvoor moet de logger niet alleen de cURL-klasse kennen, maar ook inzicht hebben in hoe andere klassen die klasse gebruiken. Dat wil je niet. Je logt de warning van A en als die ontaardt in een notice bij B, dan log je die opnieuw.
A weet helemaal niet dat B gaat loggen. A is zich zelfs niet bewust van het bestaan van B. En je wilt ook geen A bouwen die per se door B moet worden gebruikt omdat er anders niets wordt gelogd.
Een klasse hoeft daarom ook niet te weten wanneer de logger een mail bij een kritieke fout de deur uitdoet naar de juiste dienstdoende persoon. Dat maakt klassen dan té "logger aware". Alleen een level is ruim voldoende; daarna is het aan de logger om te bepalen hoe er wordt gelogd.
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
<?php
try {
$this->cacher->cache($data, 'foo');
catch (CacherException $e) {
$this->exception_handler('Could not cache data', $e, WARNING);
}
?>
try {
$this->cacher->cache($data, 'foo');
catch (CacherException $e) {
$this->exception_handler('Could not cache data', $e, WARNING);
}
?>
of
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
<?php
try {
$config = $this->database->get('website_config');
catch (DatabaseConnectionException $e) {
$this->exception_handler('No database connection', $e, ERROR);
}
?>
try {
$config = $this->database->get('website_config');
catch (DatabaseConnectionException $e) {
$this->exception_handler('No database connection', $e, ERROR);
}
?>
Een class method vangt dus ergens een exception op, en afhankelijk van de aard van die exception wordt in sommige gevallen de exception handler ingeschakeld. Aan die exception handler wil ik dan een level kunnen meegeven. Die handler weet aan de hand van het level wat er vervolgens moet gebeuren.
Gewijzigd op 25/11/2013 16:21:21 door Ozzie PHP
Quote:
Zorg dat alle 8 levels beschikbaar zijn. Hoeveel je er daadwerkelijk gebruikt is een ander verhaal. Das is namelijk jouw keuze.
Wat heb jij tegen wel 5(!(???)) extra levels toevoegen zodat je de zelfde waarde door kan geven aan een Psr logger?
Ozzie PHP op 25/11/2013 16:19:46:
Een class method vangt dus ergens een exception op, en afhankelijk van de aard van die exception wordt in sommige gevallen de exception handler ingeschakeld. Aan die exception handler wil ik dan een level kunnen meegeven. Die handler weet aan de hand van het level wat er vervolgens moet gebeuren.
In A treedt een onverwachte fout op. Gelukkig niet zo erg: je had het ding namelijk in een if verpakt die bij false een exception gooit. Aangekomen bij B blijkt de fout toch minder onschuldig te zijn: het PHP-script crasht hard in de try, nog voordat het in de catch belandt. Hoe wil je dan nog bij een logger uitkomen?
Als je het loggen almaar vooruit schuift, kom je er soms niet meer aan toe. Of je vergeet het, want van uitstel komt afstel en "dat doe ik morgen wel". Ondertussen blijven bugs onopgemerkt.
Kun je nog het verschil uitleggen tussen FATEL en ERROR?
Uit jouw link (thanks):
Emergency: system is unusable
Alert: action must be taken immediately
Critical: critical conditions
Error: error conditions
Warning: warning conditions
Notice: normal but significant condition
Informational: informational messages
Debug: debug-level messages
Ik zie het hier staan... maar ik weet niet hoe ik dan onderscheid moet maken. Wat is bijvoorbeeld het verschil tussen een error en critical? En tussen critical en alert? Dat komt toch allemaal op hetzelfde neer?
@Ward:
Ik voel dat je me iets probeert duidelijk te maken, maar ik zie het licht nog niet helemaal. Kun je eens schematisch een praktijkvoorbeeldje geven van wat je bedoelt?