Fout behandelen als error of warning

[van.der.schulting]

Allereerst even de situatie schetsen:
Ik heb een applicatie die een array van objecten afloopt. Alle objecten zijn deels afhankelijk van een externe server (applicatie) waar ik geen invloed op heb. Helaas is deze externe applicatie relatief onstabiel. Voorheen liet ik een object (en dus mijn applicatie) crashen als de externe applicatie crashte / niet reageerde binnen een x aantal pogingen. Zo wist ik zeker dat mijn applicatie geen objecten oversloeg.

Een betere benadering is de applicatie niet te laten crashen, maar het object in een tijdelijke 'error' databasetabel te plaatsen en door te gaan met het volgende object. De errors kan ik dan op een later moment fixen, zonder dat de rest van mijn applicatie stil staat.

Nu mijn punt:
Zelf denk ik dat het het beste is om de gecrashte objecten zelf als een error te behandelen en in mijn applicatie zelf een warning te genereren. Ik vraag mij echter af of dit de juiste benadering is. Is dit een goede benadering of weet iemand een betere manier?

edit:

Mijn overweging om de gecrashte objecten als een error te beschouwen en in de applicatie zelf een warning te genereren, is dat feitelijk het gecrashte object 'ermee stopt', terwijl mijn applicatie zelf 'gewoon door zal gaan'. Maar is mijn overweging juist?

PS
Ik heb expres details zoals de programmeertaal waarin het geschreven is weggelaten om het zo abstract mogelijk te benaderen.

[ Voor 10% gewijzigd door van.der.schulting op 05-08-2011 22:57 ]

[Freeaqingme]

Los van het feit dat dit wel php /moet/ zijn (php is de enige taal waarin je errors/warnings throwt afaik), zou ik gewoon voor exceptions gaan Dit is toch veel makkelijker?

[van.der.schulting]

Freeaqingme schreef op vrijdag 05 augustus 2011 @ 22:56:
Los van het feit dat dit wel php /moet/ zijn (php is de enige taal waarin je errors/warnings throwt afaik), zou ik gewoon voor exceptions gaan Dit is toch veel makkelijker?

Fout Het is Ruby.

Ik vraag me af of het makkelijker is, immers moet je bij een error gaan werken met een 'rescue' blok, anders stopt je applicatie ermee. Bij een warning zal de applicatie zelf gewoon blijven doorgaan.

[kluyze]

Freeaqingme schreef op vrijdag 05 augustus 2011 @ 22:56:
Los van het feit dat dit wel php /moet/ zijn (php is de enige taal waarin je errors/warnings throwt afaik), zou ik gewoon voor exceptions gaan Dit is toch veel makkelijker?

Ik lees dit helemaal anders. Hij heeft het helemaal niet over een error in zijn applicatie maar over het flaggen van een object als 'niet behandelt' of een object de status 'ERROR'/'UNVALID' geven.

Dit lijkt me gewoon een implementatie keuze, die jij of jouw opdrachtgever even moet overleggen.

Enige bedenking die ik heb;
Als een object niet behandeld is omwille van een fout in de communicatie, waarom werkt het volgende object dan wel? Als bij de volgende poging de communicatie terug is, waarom kan je dan het vorige foute object niet opnieuw behandelen?

[RobIII]

Dit is meer iets voor SEA
PRG >> SEA

Ik ben wel eens benieuwd naar wat je onder een "gecrashed object" verstaat

Afhankelijk van je functionele eisen ga je natuurlijk een "fout (/gecrashed?) object" afhandelen en eventuele daarna volgende objecten worden ook weer afhankelijk van diezelfde eisen afgehandeld. Ik zie niet hoe wij hier een zinnige input op moeten kunnen geven.

Als tijdens het verwerken van orderregels halverwege de order een fout optreedt wil je misschien wel de hele order flaggen/afbreken/whatever maar daaropvolgende orders weer verder verwerken. Maar in 't geval van een kerncentrale wil je misschien niet helemaal vrolijk doorgaan met 't toevoegen van uranium (of weet ik het ) in de kern als 1 van je sensors defect is en een "fout/crash" aangeeft (en misschien ook (juist?) wél Wat weet ik nou van kerncentrales ).

In sommige gevallen wil je dat een applicatie afbreekt/kapt/stopt/crashed om verdere schade te voorkomen, in andere gevallen wil je een applicatie hebben die probeert nog te redden wat er te redden valt of die zelfs gewoon bepaalde 'imperfecties' negeert; het zou wat zijn als een browser op z'n bek ging van 'foute' HTML bijvoorbeeld

[ Voor 111% gewijzigd door RobIII op 06-08-2011 02:51 ]

[Voutloos]

van.der.schulting schreef op vrijdag 05 augustus 2011 @ 23:00:
Ik vraag me af of het makkelijker is, immers moet je bij een error gaan werken met een 'rescue' blok, anders stopt je applicatie ermee.

Dat is misschien wel de belangrijkste feature van Exceptions. Je moet ze afhandelen en je kan in de context waar je ze vangt vaak een betere beslissing op dat vlak maken, ipv dat je in een low level stukje code of generieke error handler allemaal vieze details van je programma moet weten.

Op basis van Rob zn voorbeeld: als een orderregel een Exception gooit, moet de code die door de orderregels loopt daar iets mee doen en die kan dan bv. besluiten de hele order te stoppen. Wil je die beslissing in de orderregel code zelf maken, mag je dat met magische return values of globale variabelen met een status gaan doen.

[/klassieke error vs exception discussie, zie Het Internet voor meer]

[van.der.schulting]

RobIII schreef op zaterdag 06 augustus 2011 @ 02:38:
Ik zie niet hoe wij hier een zinnige input op moeten kunnen geven.

Die hebben jullie al gegeven; het is een ontwerpbeslissing

[YopY]

Ten eerste: Wat je hier doet is (en ik geloof zo dat je dat zelf ook wel door hebt) symptoombestrijding: de externe server is niet betrouwbaar, en in een ideale situatie zou je dat oplossen ipv het symptoom (dwz dat transacties mislukken) proberen op te lossen.

Ten tweede, aangezien het oplossen (blijkbaar) niet mogelijk is, een goeie en redelijk normale oplossing is om te doen wat jij ongeveer zegt. Ik zou het echter andersom doen: ipv de 'gecrashte' objecten (dwz die niet behandeld zijn) apart op te slaan zou ik juist alle objecten opslaan (al dan niet in een DB), en die, mits de transactie met de brakke externe server gelukt is, markeren als 'geslaagd' en/of verwijderen. Zo krijg je een (persistent) queue, en ben je tegelijkertijd ook je lijst met te verwerken objecten niet kwijt indien je eigen applicatie crasht (of de stroom uitvalt, of de aarde vergaat, of wat dan ook).

Om de vraag in het topic te beantwoorden: Omdat je met redelijke zekerheid kunt zeggen dat de externe service niet betrouwbaar is, en je er toch niks aan kunt doen als hij toch down is, zou ik het een waarschuwing houden en je applicatie zodanig bouwen dat hij ermee om kan gaan. Een error zou ik alleen doen als je er zelf iets aan kunt doen.

[ Voor 16% gewijzigd door YopY op 08-08-2011 10:04 ]