Toon posts:

Hoe om te gaan met logging en exceptions in framework?

Pagina: 1
Acties:

  • Haan
  • Registratie: februari 2004
  • Laatst online: 24-09 11:09
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 :)

Kater? Eerst water, de rest komt later
Last.fm profiel


  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

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? :)

As always, we are nailed to a cross of our own construction.


  • AtleX
  • Registratie: maart 2003
  • Niet online

AtleX

Tyrannosaurus Lex 🦖

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]

12x360Wp = 4320 Wp @ Growatt 4200TL-XL. Zuid met helling 13° op plat dak.


  • creator1988
  • Registratie: januari 2007
  • Laatst online: 24-09 14:10
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
  • Registratie: februari 2004
  • Laatst online: 24-09 11:09
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]

Kater? Eerst water, de rest komt later
Last.fm profiel


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 23:40

Janoz

Moderator Devschuur®

!litemod

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.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee