Exception handling in 24/7 apps

[DrDelete]

Ik ben bezig met een applicatie/engine die 24/7 "luistert" naar binnenkomende data van sensoren in C# 2.0 (Visual Studio 2005). Het geheel is een console app, er vindt geen UI interactie plaats.

Een algemene vraag (onafhankelijk van het ontwikkelplatform):

Stel dat er een unhandled exception plaatsvindt, is het dan verstandig om de app te laten killen (dus niks bijzonders doen) ? Je zou bijv. ook de exceptie kunnen opvangen en een nieuwe instance + run van de engine laten doen in een oneindige loop.

Persoonlijk vind ik dat unhandled exceptions niet afgevangen mogen worden. De ontwikkelaar dient zo spoedig mogelijk geinformeerd te zijn over de exception en hoe het te reproduceren is. Er moet dan wel een mechanisme worden gebouwd die alle exceptions veilig logt naar bijv. de eventlog. Eventueel moet er een notificatiemechanisme worden bijgebouwd die de operator waarschuwt indien de applicatie plat gaat.

[Cyphax]

Ik zou alles afvangen, en dan per exception kijken of ie erg genoeg is om de applicatie te killen. Dan heb je ook alle vrijheid om te loggen/mailen etc. als er iets misgaat. Of het nut heeft een applicatie te herstarten hangt dus ook af van wat er misgaat. Als een van de afhankelijkheden van het ding (een databaseserver) ermee ophoudt heeft het weinig zin om elke keer je applicatie te laten herstarten.

[DrDelete]

Cyphax schreef op donderdag 15 februari 2007 @ 14:45:
Ik zou alles afvangen, en dan per exception kijken of ie erg genoeg is om de applicatie te killen. Dan heb je ook alle vrijheid om te loggen/mailen etc. als er iets misgaat. Of het nut heeft een applicatie te herstarten hangt dus ook af van wat er misgaat. Als een van de afhankelijkheden van het ding (een databaseserver) ermee ophoudt heeft het weinig zin om elke keer je applicatie te laten herstarten.

Dat wordt wel lastig om per exception te gaan bekijken of ie erg genoeg is, dat kunnen er namelijk heel veel zijn (voornamelijk die gelegen zijn in de .NET framework API)

[Cyphax]

DrDelete schreef op donderdag 15 februari 2007 @ 14:53:

Dat wordt wel lastig om per exception te gaan bekijken of ie erg genoeg is, dat kunnen er namelijk heel veel zijn (voornamelijk die gelegen zijn in de .NET framework API)

Je kunt het af laten hangen van het type exception.
Alle IOExceptions bijvoorbeeld zijn critical, maar een IndexOutOfRangeException bijvoorbeeld weer niet.

En ja, kan lastig zijn, natuurlijk, maar het is nog veel lastiger als je applicatie om een wat minder belangrijke exception ermee kapt, of bij kritieke exceptions toch doorgaat.

[Alarmnummer]

Cyphax schreef op donderdag 15 februari 2007 @ 15:08:
[...]

Je kunt het af laten hangen van het type exception.
Alle IOExceptions bijvoorbeeld zijn critical, maar een IndexOutOfRangeException bijvoorbeeld weer niet.

Een IOException is minder critical dan een indexoutofrangexception omdat een ioexception iets is waar je rekening mee dient te houden. Je weet verder niet wat de oorzaak is van een indexoutofrangeexception, bv een programmeerfout in een concurrency structuur waardoor je op een verkeerde index loopt te werken. Na afloop is deze concurrency structuur in een invalid state gekomen en is wellicht niet meer te gebruiken door andere threads.

[Cyphax]

Alarmnummer schreef op donderdag 15 februari 2007 @ 15:59:
[...]

Een IOException is minder critical dan een indexoutofrangexception omdat een ioexception iets is waar je rekening mee dient te houden. Je weet verder niet wat de oorzaak is van een indexoutofrangeexception, bv een programmeerfout in een concurrency structuur waardoor je op een verkeerde index loopt te werken. Na afloop is deze concurrency structuur in een invalid state gekomen en is wellicht niet meer te gebruiken door andere threads.

Het lijkt me weer afhangen van hoe je applicatie in elkaar zit, ik heb hier wel een applicatie staan waar een IOException erger is dan een IndexOutOfRangeException (die overigens ook niet genegeerd wordt, maar het kan gewoon zijn dat er een keer een bestand tussenzit dat niet helemaal klopt, en dan moet de applicatie wel verder gaan voor een volgend bestand)
Overigens zou zo'n exception niet op moeten treden tenzij er echt iets niet in orde is, omdat voordat een file wordt geopend eerst wordt gecontroleerd of het ding wel bestaat.

Je kunt met Java geloof ik per try meerdere exceptions af laten vangen, toch? Ik weet niet of dat met .NET ook kan ('k zal het eens proberen). Is in ieder geval wel handig voor operaties die meerdere typen exceptions kunnen throwen.

[ Voor 14% gewijzigd door Cyphax op 15-02-2007 16:09 ]

[mulder]

Maar dit speelt dan toch eigenlijk alleen in ontwikkeling? Ik zou in een live omgeving de error willen loggen en op de hoogte gesteld willen worden, maar de applicatie moet verder gaan/opnieuw starten.

[DrDelete]

Don Facundo schreef op donderdag 15 februari 2007 @ 16:09:
Maar dit speelt dan toch eigenlijk alleen in ontwikkeling? Ik zou in een live omgeving de error willen loggen en op de hoogte gesteld willen worden, maar de applicatie moet verder gaan/opnieuw starten.

precies....

[akaIDIOT]

In java is het in ieder geval mogelijk in de try-clause een finally aan te geven, waar je een blok in gooit wat sowieso wordt uitgevoerd. Wordt afaik ook wel omschreven als de clean-up code. Wellicht bestaat een dergelijke constructie in meer talen.
Op deze manier zou je netjes een log kunnen aanmaken bij het vangen van een kritieke exceptie, en als final omdat je een perpetual app draait je app kunne herstarten. Op die manier heb je een beetje een tussenweg; zowel het netjes afhandelen van je excepties als het feit dat je app herstart omdat ie nou eenmaal nodig is...

[MSalters]

Exception handling in 24/7 applicaties is een systeem beslissing, geen taal iets.

Belangrijke vragen zijn: wat betekent 24/7 precies? Applicaties met 100% uptime bestaan niet, dus wat zijn jouw concrete eisen rondom downtime? Hoe escaleer je een probleem? Waarheen? Is het een real-time systeem? Zijn er wettelijke eisen?

[Not Pingu]

DrDelete schreef op donderdag 15 februari 2007 @ 14:40:
Stel dat er een unhandled exception plaatsvindt, is het dan verstandig om de app te laten killen (dus niks bijzonders doen) ? Je zou bijv. ook de exceptie kunnen opvangen en een nieuwe instance + run van de engine laten doen in een oneindige loop.

Als je je applicatie restart, loop je het risico binnenkomende data te missen. Waarom zou het zover moeten komen? Even aangenomen dat je binnenkomende data per 'bericht' asynchroon afhandelt, zou er binnen de afhandeling van het bericht een exceptie kunnen optreden, of in bijv. de netwerkverbinding (verbinding verbroken oid. waardoor je socket weg is).

Bij een exception binnen de afhandeling van een bericht, kun je in het ergste geval altijd de thread gewoon afkappen en de ruwe data backuppen of verloren laten gaan mocht backuppen niet lukken.
Alleen bij een exception op bovenliggend niveau zul je dingen opnieuw moeten initialiseren (netwerkverbinding) en als dat niet lukt (kabel stuk oid) alarm slaan.

Cyphax schreef op donderdag 15 februari 2007 @ 16:07:
[...]

Het lijkt me weer afhangen van hoe je applicatie in elkaar zit, ik heb hier wel een applicatie staan waar een IOException erger is dan een IndexOutOfRangeException (die overigens ook niet genegeerd wordt, maar het kan gewoon zijn dat er een keer een bestand tussenzit dat niet helemaal klopt, en dan moet de applicatie wel verder gaan voor een volgend bestand)

offtopic:
Dan vraag ik me wel even af hoe je IndexOutOfRangeExceptions dan afvangt, of sla je de iteratie gewoon over als dat gebeurt?