Hoe om te gaan met logging en exceptions in framework?

[Haan]

Op mijn werk maken we veel gebruik van een zelfgeschreven (grotendeels door mij) framework, taal is C#.

Momenteel is het zo dat de meeste exceptions die op kunnen treden binnen het framework worden afgevangen en gelogd (mbv log4net). Voordeel is dat het lekker makkelijk in gebruik is, nadeel is dat je afhankelijk bent van log4net om de exceptions terug te kunnen vinden, en soms wil je zelf nog eens wat met een exception doen en dan kan dat niet meer.

Daarom wil ik het zo aanpassen dat exceptions standaard niet binnen het framework worden afgevangen, maar dat het nog wel mogelijk is door een andere constructor met een boolean 'catchExceptions' te gebruiken.

Nu zit ik alleen nog met de overweging of ik de exceptions dan nog wel moet loggen binnen het framework, of dat ook de verantwoordelijkheid wordt van de classes die het framework aanroepen. Ik neig er zelf naar om dat wel binnen het framework te houden.

Graag hoor ik jullie meningen en / of andere suggesties

[CodeCaster]

Als iemand jouw framework gebruikt en iets verkeerd doet (The method cannot complete its defined functionality / An inappropriate call to an object is made, based on the object state / When an argument to a method causes an exception) wil 'ie dat graag weten denk ik.

Aardig dat jouw framework dat afvangt, maar hoe komt de aanroepende methode er dan achter dat een fout is opgetreden?

[AtleX]

Bij mij bubbelt het allemaal lekker naar boven. Als je alles af gaat vangen binnen je framework, hoe weet de aanroepende code dan dat er iets fout gegaan is?

[edit]
Waarom hebben jullie er eigenlijk voor gekozen om alle exceptions in te slikken? Wat was de redenatie erachter? En hoe informeer je 'gebruikers' nu als er iets niet goed gaat?

[ Voor 37% gewijzigd door AtleX op 02-11-2010 14:12 ]

[creator1988]

Het framework weet toch niet wat een applicatie wel of niet met de data zou willen doen? Exceptions throwen dus, nooit zomaar inslikken. .NET doet dit zelf ook niet, NHibernate doet dit ook niet, etc.

NHibernate logt overigens wel standaard naar log4net (althans in de versie die wij nog gebruiken), zodat je wel fouten terug kan vinden als de client nalaat om dit soort zaken te loggen.

[Haan]

Het framework is eerst klein begonnen en toen was het handig om zelf geen rekening te hoeven houden met exception (overigens wordt alleen 1 specifiek type exception afgevangen, het is niet zo dat het framework een catch (Exception e) doet.. ). Logging was toen ook nog anders, daarmee was het toen nog niet zo'n issue. Maar dat het afvangen van exceptions nu niet handig is, was ik al met jullie eens

Ik vraag me nu vooral nog af of het wel handig is om te blijven loggen, of om dat ook buiten het framework te leggen, maar het best is denk ik om het wel binnen het framework houden om de reden die creator1988 ook al aangeeft.

[ Voor 9% gewijzigd door Haan op 02-11-2010 14:31 ]

[Janoz]

Als log4net net zo werkt als log4j (waar het van afgeleid is) zie ik niet in waarom je de logging uit wilt besteden. Ook als het framework al af is is het soms heel handig om de logging van het framework op debug te zetten wanneer je tegen onverwacht gedrag aanloopt.

Exceptions zal ik ook zeker niet op gaan eten, tenzij je echt daadwerkelijk zeker weet hoe je het op die plek op kunt en wilt lossen. Wat ik zelf nog wel eens doe is de exception wrappen in een eigen exception. Wanneer je bijvoorbeeld een dele van je framework data ophaalt uit een willekeurige bron wil je niet dat hij de ene keer een IO exception terug gooit omdat het van het filesystem wordt gelezen terwijl het in het andere geval ineens een database exception terug komt omdat in dat geval toevallig data uit een dataabase gehaald wordt. In beide gevallen wil je gewoon een soort generieke data access exception terug geven waar je gebruiker iets mee kan.