[php] Global exceptions loggen. Zelfs na try / catch

[IM_YOUR_MAMA]

Ik onderhoud nu een grote web applicatie gemaakt in php (7.3) met laravel (5.7).

Het probleem wat ik nu heb is dat aan mij is gevraagd of ik kan inbouwen dat alle exceptions worden gelogged, Ook de exceptions die door een try catch block zijn afgehandeld. ik heb verschillende oplossingen gevonden online maar die zijn niet goed toepasbaar.

Wat ik heb gevonden (De oplossingen kan door de grote van de applicatie niet worden gedaan):
1:

code:

try {
        //Doe iets wat kan failen
    } catch (\Exception $e) {
        error_log($e->getMessage(), ...);
        //Orginele code
    }

2:

(dashboardcontroller.php)

code:

try {
        throw new \Exception('custom throwed exception');
    } catch (\Exception $e) {
        Log::info('Exception catched');
    }

Exceptions\Handler.php

code:

public function report(Exception $exception)
    {
        Log::info($exception);
        parent::report($exception);
    }

Log:

code:

[2020-03-10 17:19:09] local.INFO: Exception catched

In deze voorbeelden kan je zien dat de exceptions die worden gecatch niet worden gelogged. Maar dat is dus wel de bedoeling.

Ik heb op verschillende plekken al voor hulp gevraagt maar steeds zonder success. Ik heb ook een stackoverflow question gemaakt. Misschien is dat beter leesbaar omdat ik het beter in het engels kon uitleggen
https://stackoverflow.com...-in-the-whole-application

[Postman]

Ik neem aan dat je gebruik wil maken van de syslog functie. Dan de vraag: wat staat er in je config/logging.php bestand bij de syslog entry voor level?

[IM_YOUR_MAMA]

De level staat op 'debug'. De applicatie gebruikt geen syslog. Hij staat op 'stack'. De logging van de exceptions die niet worden gecatched worden opgevangen door een aangepaste versie van laravel/telescope

[RobIII]

IM_YOUR_MAMA schreef op woensdag 11 maart 2020 @ 16:44:
Het probleem wat ik nu heb is dat aan mij is gevraagd of ik kan inbouwen dat alle exceptions worden gelogged,

Ik vind dat eigenlijk een raar verzoek; los van hoe je 't zou (willen gaan) oplossen. Exceptions die door een catch afgehandeld worden* zijn nou meestal niet interessant om te loggen. Het zijn de 'uncaught exceptions' die je doorgaans wil loggen.

_{* en die niet al gelogd worden...}

Exceptions moet je natuurlijk nooit voor program-flow gebruiken, maar soms gebeurt het wél:

code: pseudocode

if (fileExists('foo.txt')) {
  fileDelete('foo.txt'); // Kans op race-condition
}

Versus:

code: pseudocode

try {
  fileDelete('foo.txt')
catch (IOException) {
  // NO-OP
}

Of bijvoorbeeld:

code: pseudocode

while (true) {
  try {
    item = queue.Receive(10); // Wait max. 10 seconds
    process(item);            // Process item
  } catch (TimeOutException) {
    // Nothing on queue, handle other stuff and then continue waiting...
    DoStuff();
  }
}

Bovenstaande zaken zijn vrij normaal / vaak voorkomend (niet dat wat ik hierboven laat zien een goed ontwerp is, maar soms ben je afhankelijk van libraries, 3rd party systemen of ander spul waar je weinig aan kunt doen behalve exceptions handlen).

Wil je dat soort shizzle allemaal in je logging hebben? Lijkt me sterk. Zoiets wil je case-by-case bekijken en dat is dan ook hoogst waarschijnlijk de reden dat ik geen enkele taal ken die een voorziening treft a-la "haak hier maar aan in elke catch". Het is vrij normaal (ironisch genoeg) dat er in allerlei code uitzonderingen (exceptions) optreden. Ze zijn natuurlijk nog steeds uitzonderlijk/exceptioneel, maar vervuilen wel je logs ontzettend als je élke exception gaat loggen. Het klinkt me dan ook héél erg in de oren dat iemand denkt een 'silver bullet' te hebben gevonden die dat stiekem niet is.



(En voor wie het nog eens in het Dunglish wil nalezen: linkje)

[ Voor 47% gewijzigd door RobIII op 11-03-2020 18:04 ]

[johnkeates]

Dit is iets wat je eerder gewoon hard wil laten crashen, daar een report van wil krijgen van een supervisor en een automatische herstart met desnoods een rollback naar de vorige versie, terwijl ondertussen andere requests naar andere workers gestuurd worden. Of heb je het hier over een enkele runtime op een enkele box met een knutselwerk-lifecyle? Meestal ga je pas zo diep als je de basis al goed hebt. Heb je dat niet, begin daar dan eerst. (en als je de basis al goed hebt komen dit soort vragen meestal niet meer voor, vandaar deze antwoordconstructie )

[ Voor 22% gewijzigd door johnkeates op 11-03-2020 17:12 ]

[DJMaze]

@IM_YOUR_MAMA gewoon de C code van PHP aanpassen of een PHP extensie schrijven die aan de 'catch' hangt.

Succes met schijfruimte!

[ Voor 11% gewijzigd door DJMaze op 11-03-2020 20:19 ]

[DataGhost]

IM_YOUR_MAMA schreef op woensdag 11 maart 2020 @ 16:44:

code:

try {
        //Doe iets wat kan failen
    } catch (\Exception $e) {

Het gaat hier eigenlijk al mis. Je wilt iets als

code:

} catch (SpecificException $e) {

voor de exceptions die je verwacht, en dan komen de echte exceptions (die je niet verwacht) vanzelf bovendrijven.

[MueR]

Eigenlijk met wat RobIII zegt. Exceptions die je lokaal afvangt zijn helemaal niet interessant want die verwacht je, mits je niet overal een } catch (\Exception $e) { doet. Voor alle Exceptions die door je try/catch glippen heb je de set_exception_handler om te loggen, want dat zijn de exceptions die wel boeien: die laten de zut crashen. Bij de rest zul je handmatig moeten loggen.

[Gomez12]

Wat is het idee achter het loggen van alle excepties? Is dat om beter inzicht te krijgen en het later desgewenst terug te draaien (omdat het gewoon niet overal nodig is) dan kan ik het begrijpen, maar dan zou ik het simpelweg toepassen door alle catches aan te passen.
Dat kost je x tijd, maar je kan daarna wel alles weer uitschakelen wat niet gelogged hoeft te worden.

Terwijl je met een echte globale oplossing je geen enkele filtering kan krijgen en je altijd met bagger blijft zitten.

Wil je dus :
- Beginnen met alles (inclusief bagger) om daarna de bagger weer selectief uit te schakelen, zodat je effectieve logging overhoudt?
- Echt alles blijven loggen met bagger erbij waardoor je een onleesbare brei creeert?

[IM_YOUR_MAMA]

Ik ben het nu eens dat het niet handig is om dit globaal te doen en het case by case moet. Ondanks dat het betekend dat er veel changes in de code moet worden gemaakt. Ik zal dit overleggen met mijn team en daaruit vervolg stappen maken en uitvoeren.

Iedereen bedankt voor de info en de hulp!

[RobIII]

Gomez12 schreef op donderdag 12 maart 2020 @ 09:43:
Terwijl je met een echte globale oplossing je geen enkele filtering kan krijgen

Nou ja... in een beetje logging framework kun je prima zeggen dat je alleen excepties van type X wil loggen of alleen exceptions uit namespace Y of...

Voorbeeldje: Nlog

XML:

<rules>
  <logger name="*" minlevel="Info" writeTo="XXX" />
  <logger name="Name.Space.*" minlevel="Debug" writeTo="YYY" />  
  <logger name="*.FooException" minlevel="Trace" writeTo="ZZZ" />
  <logger name="*.Library.*" minlevel="Warn" writeTo="XYZ" />
</rules>

En dan pak ik nu NLog, maar veel van de logging frameworks die ik ken of wel eens aan geroken heb ondersteunen wel iets van die strekking.

Maar dan moet je nog steeds in de catch wel je exception(s) naar je logging gooien. En dan besluit je logging framework wel óf de exception gelogd moet worden en, zo ja, waar naar toe.

[ Voor 26% gewijzigd door RobIII op 12-03-2020 11:40 ]