Uiterst goed dat iedereen in dat bedrijf dan zonder internet zit.
Dit is helemaal geen goede manier om de fout af te handelen, men moet hier rekening mee houden, en niet redeneren dat als 1 iemand iets verkeerd doorstuurt dat heel het bedrijf/organisatie of meervoud van deze zonder internet zullen zitten.
Dit is naar mijn mening een compleet verkeerde aanpak.
De rede waarom ik dit vind is omdat een assert in c++ gewoon op waarde 0 checkt en indien dat het geval is dan stopt het programma, je kan dus evengoed dit schrijven:
if (checkValue == 0) {
handleError(whatever_parameters_you_need);
}
Deze manier van programmeren heeft geleidt dat het programma op zich een slechte reputatie gekregen heeft en erger ervoor geleidt dat vele bedrijven zonder internet zitten omdat de programmeur dacht van het programma gewoon te sluiten in plaats van de fout op een deftige manier af te handelen.
Ik ga dus helemaal niet akkoord met wat jij hier goed vindt. Het is inderdaad beter dan strcpy(myOverflowableBuffer, value); maar verre van een goede of beter gezegd doordachte oplossing!
Ja ik ben te algemeen door te zeggen "zonder internet"
[Reactie gewijzigd door _revised_ op donderdag 30 juli 2009 12:38]
Ik heb dit specifieke stuk code niet bekeken, dus misschien dat ze hier iets heel geks doen, maar...
Normaal gesproken gebruik je asserts alleen voor dingen die je zelf onmogelijk acht. Als je assert triggered is er iets zo enorm mis dat je het redelijkerwijs niet meer op kan lossen.
Als er een mogelijkheid is om het probleem te herstellen, dan moet je die fout inderdaad opvangen en verder gaan.
Als het echter niet mogelijk is om het probleem op te lossen, dan kun je beter het programma gecontroleerd afbreken dan maar proberen door te draaien.
Als er een mogelijkheid is om het probleem te herstellen, dan moet je die fout inderdaad opvangen en verder gaan.
Als het echter niet mogelijk is om het probleem op te lossen, dan kun je beter het programma gecontroleerd afbreken dan maar proberen door te draaien.
In feite dus net zoiets als een kernel panic, maar dan op applicatieniveau
Want als een kernel te maken krijgt met geheugencorruptie o.i.d., is het meestal ook over en uit, met als je geluk hebt een memorydump.
Als er iets misgaat buiten de applicatie, waar de applicatie geen invloed op heeft, kan het soms erg lastig of onmogelijk zijn om daar omheen te werken omdat je niet op iets kan anticiperen wat mogelijk onvoorspelbaar gedrag vertoont.
[Reactie gewijzigd door Sfynx op donderdag 30 juli 2009 18:38]
In een perfecte wereld, waarin programmeurs oneindig veel tijd en geen deadlines hebben, zou je gelijk hebben.
In het echt kost het schrijven van tientallen handleError() routines echter vreselijk veel tijd. Wat een assert() eigenlijk doet (ik heb de source niet bekeken, dus ik kan niet garanderen of dat echt de bug is in BIND9) is:
criticalValue = someSubroutine ( params );
// someSubroutine should never fail, criticalValue should never be zero
if (criticalValue = 0)
{
// if this code executes something really weird is happening
exit ( ASSERT_FAILED );
}
Is dit perfect? Nee, als je het perfect wilt doen dan zul je moeten bewijzen (op de wiskundige, waterdichte manier) dat die someSubroutine() inderdaad nooit 0 kan returnen. Maar, zelfs in dat geval zou ik er zelf voor kiezen om de assert() te laten staan: het kost weinig CPU-tijd en ik heb nog altijd liever een gecontroleerde crash, die exact aanwijst welke assert() fout ging (en dus welk bewijs kennelijk toch een fout bevat) dan ongecontroleerd verder draaien en we zien wel wanneer we ongecontroleerd crashen en of er misschien iets te exploiten is voor die tijd. Bovendien, zelfs al is dit niet perfect, het is vele malen beter dan de implementatie die meestal gekozen wordt:
someSubroutine ( params );
waarbij de returncode letterlijk weggegooid wordt en er überhaupt niet gecontroleerd wordt of er iets onverwachts is gebeurd!
Het idee van assert is oorspronkelijk dat dit een precompiler trucje is. Als je de build configuratie goed instelt, dan wordt tijdens het compileren de hele check uit het programma gegooid.
Asserts zijn bij uitstek bedoeld om de interne consistentie van het programma tijdens het testen te bewaken. Als je tests uitputtend genoeg zijn, dan ga je "alle" mogelijk codepaden door en dan kunnen asserts je in een vroeg stadium op een fout wijzen...
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
10:19
09:04
Door 
![[show]](http://tweakimg.net/g/if/comments/button_down.png "Reactie uitklappen")
receives a specially crafted dynamic update message an
