[alg] hoe lief moet je zijn?

[Alarmnummer]

Hoe lief moet je zijn met het schrijven van je methodes? Ik heb er een enorme rothekel aan als ik methodes heb die geen foutmelding gegeven en er toch iets niet helemaal in de haak was:

code:

setLeeftijd(int leefijd){
     if(leeftijd<0)
          _leeftijd = 0;
     else
          _leeftijd = leeftijd;
}

Dit wil ik dus niet, ik wil gewoon een dikke foutmelding:

code:

setLeeftijd(int leefijd){
     if(leeftijd<0)
           throw new IllegalArgumentException("....");    
     _leeftijd = leeftijd;
}

In het geval van leeftijd, is er dus echt iets fout gegaan op het moment dat je aanroept met -15 en dan wil je dus een foutmelding.

Maar in sommige gevallen is de grens wat minder duidelijk. Stel je hebt een of ander object met een lijst met listeners, en je wilt een listener removen die niet in de list zit. Ga je dan een foutmelding opwerpen? Of ga je gewoon verder alsof niets aan de hand was? Tenslotte heeft niemand er last van dat dat object niet in die lijst zat. Op het moment dat je dan een fout gaat introduceren, zorg je ervoor dat deze fout opgemerkt wordt door een programmeur (en dus gaat verhelpen). Aan de andere kant heb je een api die een lading (misschien onnodige) fouten opwerpt.

Het gaat me dus niet zozeer om dit listeners verhaal (dus kom me niet met allerlei api verwijzinginen aanzetten). Maar in hoeverre moet je lief zijn en in hoeverre streng?

[ Voor 16% gewijzigd door Alarmnummer op 02-06-2004 21:49 ]

[MaxxRide]

Ik denk dat je best streng kunt zijn. Op het moment dat je b.v. een listener verwijdert en deze blijkt al verwijdert te zijn laat je een exceptie gooien. De aanroepende functie kan dan zelf bepalen hoe belangrijk dit voor deze is.

Stel dat je in implementatie fase zit en je wilt een listener verwijderen maar je geeft om een of andere reden een verkeerde listener mee (voor het gemak een niet bestaande) terwijl je eigenlijk en bepaalde listener wilde verwijderen. Later kun je hierdoor fouten krijgen, immers de listener die je wou verwijderen is niet verwijdert, door het gooien van de exceptie oid valt dit je op.

Mocht je in run-time zitten dan wil je de user hier wellicht niet mee storen of is het minder relevant voor de werking van het systeem, dan zou je kunnen besluiten om de fout te negeren. (of te loggen of whatever).

Ik denk dus dat "te streng" geen problemen op gaat leveren maar niet streng genoeg wel problemen kan veroorzaken.

[NMe]

Het hangt er een beetje vanaf wanneer je streng/lief bent denk ik. Voor jezelf kun je het best zoveel mogelijk errors opwerpen, maar in een final build voor een gebruiker is dat misschien niet wenselijk. Een gebruiker zal het niet boeien of een item dat hij wilde verwijderen al verwijderd is, simpelweg omdat het beoogde resultaat al behaald is. Wat zou je dan nog een error gaan opwerpen? Voor jou als programmeur kan het inderdaad wel handig zijn, het kan immers op een bug wijzen.

[MaxxRide]

NMe84 schreef op 02 juni 2004 @ 22:26:
Voor jou als programmeur kan het inderdaad wel handig zijn, het kan immers op een bug wijzen.

Dat is precies de reden om streng te zijn. In eerste instantie door het opwerpen van fouten zul je nog meer ontdekken tijdens de ontwikkelingsfase. Bij de final build kun je ervoor kiezen om de fout niet door te spelen naar de gebruiker maar te loggen of b.v. door te sturen naar de helpdesk etc.

[NMe]

Pinda schreef op 02 juni 2004 @ 22:37:
Dat is precies de reden om streng te zijn. In eerste instantie door het opwerpen van fouten zul je nog meer ontdekken tijdens de ontwikkelingsfase. Bij de final build kun je ervoor kiezen om de fout niet door te spelen naar de gebruiker maar te loggen of b.v. door te sturen naar de helpdesk etc.

Dan zijn we het er dus over eens dat je wel degelijk die fout moet vinden, maar deze alleen verwerken als een harde error tijdens de ontwikkelingsfase, en in dat dat in de final nogal eens overkill kan zijn en beter gewoon gelogd kan worden?

[justmental]

Je kan het natuurlijk altijd parametriseerbaar maken, doorgaan of loggen of raisen.

[Alarmnummer]

justmental schreef op 02 juni 2004 @ 22:41:
Je kan het natuurlijk altijd parametriseerbaar maken, doorgaan of loggen of raisen.

Dan krijg je hele logge api`s en ik denk niet dat iemand hier om zit te springen.

[MaxxRide]

NMe84 schreef op 02 juni 2004 @ 22:39:
[...]

Dan zijn we het er dus over eens dat je wel degelijk die fout moet vinden, maar deze alleen verwerken als een harde error tijdens de ontwikkelingsfase, en in dat dat in de final nogal eens overkill kan zijn en beter gewoon gelogd kan worden?

Wij zijn het helemaal met elkaar eens.

Het lijkt me trouwens niet geschikt om de keuze voor raise etc te maken. Deze kun je beter door compilerdirectives (b.v.) laten afvangen in je try, catch blokken.

[Verwijderd]

Als een class/object een methode aanroept met ongeldige parameters, dient er een foutmelding te komen imo. In alle situatiets. Zeker bij grotere projecten, omdat anders het debuggen een ontzettende crime wordt. Denk ook aan het feit dat het kan zijn dat een ander jouw code moet onderhouden/debuggen, dan is het echt een must. Daarnaast is het een kleine moeite, dus waarom niet doen?

Of je al deze fouten ook keihard moet doorspelen naar de eindgebruiker is een ander verhaal. In delphi maak ik meestal afgeleiden van de Exception klasse, per klasse/object eentje. Elke applicatie krijgt z'n eigen afgeleide van de Exception klasse. Als er dan een fout optreedt, kijkt de applicatie waar deze vandaan komt. Is het z'n eigen exception-klasse, dan laat hij de fout aan de eindgebruiker zien, komt het ergens anders vandaan dan kan hij deze eventueel loggen (Als debug aanstaat).

[JaQ]

Alarmnummer schreef op 02 juni 2004 @ 22:43:
[...]

Dan krijg je hele logge api`s en ik denk niet dat iemand hier om zit te springen.

Dan maak ik dus, zolang als ik hier besef van heb, al logge api's. Over het algemeen introduceer ik in mijn code een debuging parameter. Aan de hand van de waarde van de parameter raise, log, doe ik wat anders, of doe ik niets. Ook de hoeveelheid debugginginfo bepaal ik met deze parameter.

Het grote voordeel is dat e.e.a. eenvoudig is te debuggen. Het performanceverlies (want dat zal er absoluut zijn) is volgens mij minimaal. Een nog groter voordeel is dat als je niet de enige bent die aan code werkt, een ander ook eenvoudig zijn fouten kan traceren, want je kan altijd nuttige info terug krijgen (mits je natuurlijk het debugging level maar hoog genoeg zet).

edit:
misschien dat mijn ondertitel wel precies bepaald hoe lief ik ben

[ Voor 5% gewijzigd door JaQ op 02-06-2004 22:57 ]

[ACM]

Ik denk dat als je moeite doet de foutafhandeling vriendelijk en behulpzaam te laten zijn, je best voor alle fouten de gebruiker op zijn vingers mag tikken. Maar dan moet niet bij het indrukken van een back-toets ineens een compleet formulier opnieuw ingevuld moeten worden, om maar een vaak voorkomend probleem in de html-wereld te noemen...

Verder zal je natuurlijk moeten afwegen hoe "erg" een fout is, als je een belastingapplicatie bouwt en iemand vult een negatief inkomen in op een plaats waar dat niet kan voorkomen, dan is dat wel degelijk een tik op de vingers waard. Maar iemand die een foute leeftijd invoert in een webapp die de leeftijd eigenlijk alleen maar registreert "omdat het kan" (zoals GoT hier), sja dan moet je niet te moeilijk doen...

Fouten die je controleert, maar eigenlijk niet voor mogen komen, horen natuurlijk een Exception op te leveren en bij de uiteindelijke versie zo uitgewerkt te zijn, dat het niet meer gebeurt
Daar zijn eigenlijk dingen als assertions voor bedoeld, die kan je vrij aardig uitschakelen zonder een heel grote impact op de performance, of inschakelen en veel strengere controles uitvoeren op je code, indien je er goed gebruik van maakt natuurlijk.

[curry684]

Toevallig was dit gisteravond in #devschuur nog onderwerp van discussie Ik ben zelf van de hele botte school: iedere typfout is een exception om je oren. Vind ik zelf ook nogal logisch, ik schrijf geen software die bij het converteren van string 'Pietje' naar een int gezellig met een 0 mag gaan rekenen, dat is imho in wat voor software dan ook onacceptabel. Bovendien heb ik met het exception-voor-iedere-scheet principe zelf de macht om op ieder gewenst niveau waar ik er bewust voor kies exceptions te loggen en verder in te slikken.

[Verwijderd]

Topicstarter:
Dit is nu precies de reden dat ik de exception-crap zoveel-mogelijk achterwege laat en gewoon geen 'void' returnwaarde gebruik. Zelfs bij een one-way methode die niet fout zou moeten kunnen gaan return ik een int, zodat ik over het hele programma bij elke methode kan zien of die methode goed is uitgevoerd zonder dat de loop van het programma daar onvoorspelbaar door wordt. (Wat doe je als er in 1 methode meerdere null-pointer-exceptions kunnen voorkomen, hoe weet je waar het fout is gegaan?)

Naar mijn mening zijn de error-handling-routines zoals die in java worden toegepast een van vele voorbeelden waar OO over-the-top is gegaan. IMHO is het volledig overbodig, in complexe code leid het snel tot onoverzichtelijkheid en een onnodige hoeveelheid overhead ten gevolge van absurde OO implementatie.

[ Voor 3% gewijzigd door Verwijderd op 02-06-2004 23:13 ]

[curry684]

ACM schreef op 02 juni 2004 @ 23:04:
Daar zijn eigenlijk dingen als assertions voor bedoeld, die kan je vrij aardig uitschakelen zonder een heel grote impact op de performance, of inschakelen en veel strengere controles uitvoeren op je code, indien je er goed gebruik van maakt natuurlijk.

Het argument dat een assertion sneller is dan een exception vind ik nogal bull in deze tijd van 10+ branch prediction pipelines en 3Ghz processors. De enige assertions die ik gebruik zijn static (compiletime) asserts, op runtime vind ik het gewoon ondingen. Kapotte code moet knallen, en niet alleen op debug build, al is het maar omdat je op releasebuilds juist tig keer gevoeliger bent voor data corruption.

[Amras]

Mij is geleerd om tijdens het ontwikkelen gebruik te maken van asserts om pre- en postcondities van een methode te testen. Ook heeft iedere klasse een invariant, een voorwaarde waaraan het object altijd aan moet voldoen, behalve binnen zijn eigen methoden.

Een invariant ziet er dan bijvoorbeeld zo uit:

C#:

private bool Invariant() {
    return this.leeftijd > 0;
}

Deze invariant test je aan ieder begin en eind van een public methode, verder test je ook de pre- en postcondities. In het geval van Alarmnummers setLeeftijd:

C#:

// pre: leeftijd > 0
public void SetLeeftijd(int leeftijd){
    Debug.Assert(Invariant(), "PRE: De invariant moet gelden");
    Debug.Assert(leeftijd > 0, "PRE: De leeftijd is groter dan 0");

    this.leeftijd = leeftijd;

    Debug.Assert(Invariant(), "POST: De invariant moet gelden");
}

Al zien ze er in deze korte methode niet echt handig uit, ik vind ze over het algemeen erg bruikbaar. Je haalt veel sneller fouten uit je code. De vraag blijft of je deze asserts erin wilt laten bij je uiteindelijke release.

Wat betreft het lief zijn, voor jezelf als ontwikkelaar moet je niet lief zijn, ik probeer precondities zo uitgebreid mogelijk te specificeren en daar schrijf ik dan asserts voor. Op die manier vang je zelf veel stomme errors als negatieve leeftijden oid.

edit:
damn: 8 replies meer ofzo in de tijd dat ik deze post typ

[ Voor 11% gewijzigd door Amras op 02-06-2004 23:17 . Reden: sloom ]

[curry684]

Verwijderd schreef op 02 juni 2004 @ 23:11:
[...]

Oh my god, ik zie dat je nog aan je opleiding bezig bent.... ik hoop echt dat je nog een paar dingen leert voordat ze jou op de arbeidsmarkt loslaten, want nu ben je levensgevaarlijk voor eender welk project...

[Soultaker]

curry684: misschien kun je je flame ook even met argumenten onderbouwen? We waren hier met een discussie bezig, dacht ik.

[Grijze Vos]

Amras schreef op 02 juni 2004 @ 23:14:
Mij is geleerd om tijdens het ontwikkelen gebruik te maken van asserts om pre- en postcondities van een methode te testen. Ook heeft iedere klasse een invariant, een voorwaarde waaraan het object altijd aan moet voldoen, behalve binnen zijn eigen methoden.

Een invariant ziet er dan bijvoorbeeld zo uit:

C#:

private bool Invariant() {
    return this.leeftijd > 0;
}

Deze invariant test je aan ieder begin en eind van een public methode, verder test je ook de pre- en postcondities. In het geval van Alarmnummers setLeeftijd:

C#:

// pre: leeftijd > 0
public void SetLeeftijd(int leeftijd){
    Debug.Assert(Invariant(), "PRE: De invariant moet gelden");
    Debug.Assert(leeftijd > 0, "PRE: De leeftijd is groter dan 0");

    this.leeftijd = leeftijd;

    Debug.Assert(Invariant(), "POST: De invariant moet gelden");
}

Al zien ze er in deze korte methode niet echt handig uit, ik vind ze over het algemeen erg bruikbaar. Je haalt veel sneller fouten uit je code. De vraag blijft of je deze asserts erin wilt laten bij je uiteindelijke release.

Wat betreft het lief zijn, voor jezelf als ontwikkelaar moet je niet lief zijn, ik probeer precondities zo uitgebreid mogelijk te specificeren en daar schrijf ik dan asserts voor. Op die manier vang je zelf veel stomme errors als negatieve leeftijden oid.

edit:
damn: 8 replies meer ofzo in de tijd dat ik deze post typ

In plaats van testen op je invarianten kun je natuurlijk ook bewijzen dat je invariantie in stand blijft.

[Verwijderd]

Soultaker schreef op 02 juni 2004 @ 23:26:
curry684: misschien kun je je flame ook even met argumenten onderbouwen? We waren hier met een discussie bezig, dacht ik.

Ik wil 'm wel voor je onderbouwen hoor.

Topicstarter:
Dit is nu precies de reden dat ik de exception-crap zoveel-mogelijk achterwege laat en gewoon geen 'void' returnwaarde gebruik. Zelfs bij een one-way methode die niet fout zou moeten kunnen gaan return ik een int, zodat ik over het hele programma bij elke methode kan zien of die methode goed is uitgevoerd zonder dat de loop van het programma daar onvoorspelbaar door wordt. (Wat doe je als er in 1 methode meerdere null-pointer-exceptions kunnen voorkomen, hoe weet je waar het fout is gegaan?)

Dat lijkt me an sich al onderbouwing genoeg. Ik betwijfel of iemand die praat over 'de exception-crap' uberhaupt ooit een groot project heeft moeten onderhouden, want code geschreven volgens het recept wat hij hierboven weergeeft is domweg ononderhoudbaar.

Routines die integers retourneren terwijl ze uberhaupt geen uitvoer hebben, of terwijl de invoer volledig crap was. Dat lijkt me nou niet bepaald een schoolvoorbeeld van netjes en professioneel programmeren.

[Amras]

Grijze Vos schreef op 02 juni 2004 @ 23:26:
[...]

In plaats van testen op je invarianten kun je natuurlijk ook bewijzen dat je invariantie in stand blijft.

Zou je dit iets uit kunnen leggen? Vat hem niet helemaal...

[.oisyn]

* .oisyn zweert bij assertions

Foute API calls is typisch iets dat je kunt afvangen tijdens debug builds. Ik ga geen exception gooien omdat iemand toevallig een negatieve leeftijd ingevuld heeft (nou is dat sowieso niet iets dat ik snel zal controleren, hoewel dat natuurlijk wel afhangt van de context. Zie de opmerking van ACM hierover). Exceptions gebruik ik typisch voor fouten door externe factoren, zoals een hikkende database server of het lezen van een removable drive die toevallig net verwijderd is. Voor het voorbeeld van het converteren van een string naar een int gebruik ik gewoon validatie, zeker als die string door de gebruiker is gedefinieerd. Dit omdat ik vaker niet geinteresseerd ben in een error dan wel, en als het een exception betreft dan moet ik die continu gaan afvangen met try-blocken van slechts 1 statement. Als ik dan echt een exception nodig heb bij zo'n soort functie dan maak ik wel gebruik van een helper functie die 'm valideert, en zo nodig een exception gooit. Op die manier kun je alle kanten op

[curry684]

Verwijderd schreef op 02 juni 2004 @ 23:30:
[...]

Ik wil 'm wel voor je onderbouwen hoor.

Dank je, ik ging ervan uit dat het over iemand die het over 'die exception crap van overdreven doorgeschoten object oriented troep' heeft zichzelf wel wees maar je omschrijft het goed

[Verwijderd]

curry684 schreef op 02 juni 2004 @ 23:18:
[...]

Oh my god, ik zie dat je nog aan je opleiding bezig bent.... ik hoop echt dat je nog een paar dingen leert voordat ze jou op de arbeidsmarkt loslaten, want nu ben je levensgevaarlijk voor eender welk project...

Hoe bedoel je dat? (Waarschijnlijk heb je hier goede redenen voor, maarre hier kan ik niet zoveel mee)

nevermind

[ Voor 3% gewijzigd door Verwijderd op 02-06-2004 23:33 ]

[Glimi]

Grijze Vos schreef op 02 juni 2004 @ 23:26:
In plaats van testen op je invarianten kun je natuurlijk ook bewijzen dat je invariantie in stand blijft.

Als iets een rotwerk is, dan is dat het wel. Het bewijzen van een postconidition van bijvoorbeeld een methode met een while loop is een hels en complex karwei, voornamelijk door de aliasing van de OO taal.
Kijk bijvoorbeeld in deze PDF eens hoe complex het al kan zijn in een taal die in princiepe geen aliasen toestaat.
Natuurlijk heb je er tools voor, maar deze tools moeten toch altijd flink wat hulp hebben wat dat betreft, dan het nog steeds veel meer tijd kost dan testen.

Verwijderd schreef op 02 juni 2004 @ 23:11:
Topicstarter:
[...]Zelfs bij een one-way methode die niet fout zou moeten kunnen gaan return ik een int, zodat ik over het hele programma bij elke methode kan zien of die methode goed is uitgevoerd zonder dat de loop van het programma daar onvoorspelbaar door wordt. (Wat doe je als er in 1 methode meerdere null-pointer-exceptions kunnen voorkomen, hoe weet je waar het fout is gegaan?)

1) In een try/catch bepaal jij precies wat er gebeurd. Hoezo onvoorspelbaar dan? Doorwerken met een fout omdat jij vergeet te checken, dat is onvoorspelbaar.
2) Execptions kunnen strings en pointers naar sources bevatten (hoewel bij een nullpointer dat niet zo nuttig is ) Dus dat lijkt me geen probleem.

leokennis schreef op 02 juni 2004 @ 23:35:
Conclusie hiervan:
je moet lief zijn tegen users, dan presteren ze beter. Een interface/programma dat je complimenteert en niet steeds zegt fout! , zorgt ervoor dat mensen (denken) dat:
-Het programma beter werkt
-De resultaten beter zijn
en ze gaan meer van het product 'houden'.

Maar dat is dus meer een psychologische invalshoek

Leuke invalshoek.
Helaas gaat het hier over 'lief zijn tegen programmeurs'. Het gaat er namelijk om of je een programmeur extra veel werk wilt laten doen (veel try/catch statements voor alle mogelijke gevallen) of dat je meer risico neemt.

[ Voor 50% gewijzigd door Glimi op 02-06-2004 23:46 ]

[sjaakaq]

http://www.uwtv.org/programs/displayevent.asp?rid=602

Conclusie hiervan:
je moet lief zijn tegen users, dan presteren ze beter. Een interface/programma dat je complimenteert en niet steeds zegt fout! , zorgt ervoor dat mensen (denken) dat:
-Het programma beter werkt
-De resultaten beter zijn
en ze gaan meer van het product 'houden'.

Maar dat is dus meer een psychologische invalshoek

[Amras]

.oisyn schreef op 02 juni 2004 @ 23:31:
* .oisyn zweert bij assertions

Foute API calls is typisch iets dat je kunt afvangen tijdens debug builds. Ik ga geen exception gooien omdat iemand toevallig een negatieve leeftijd ingevuld heeft (nou is dat sowieso niet iets dat ik snel zal controleren, hoewel dat natuurlijk wel afhangt van de context. Zie de opmerking van ACM hierover). Exceptions gebruik ik typisch voor fouten door externe factoren, zoals een hikkende database server of het lezen van een removable drive die toevallig net verwijderd is. Voor het voorbeeld van het converteren van een string naar een int gebruik ik gewoon validatie, zeker als die string door de gebruiker is gedefinieerd. Dit omdat ik vaker niet geinteresseerd ben in een error dan wel, en als het een exception betreft dan moet ik die continu gaan afvangen met try-blocken van slechts 1 statement. Als ik dan echt een exception nodig heb bij zo'n soort functie dan maak ik wel gebruik van een helper functie die 'm valideert, en zo nodig een exception gooit. Op die manier kun je alle kanten op

Helemaal mee eens. User input check ik in de control klasse van m'n GUI (form, frame, bla) en daar geef ik messages weer over verkeerde input, maar dieper in m'n model mag er gewoon geen negatieve leeftijd voorkomen en gebruik ik asserts.

[.oisyn]

Verwijderd schreef op 02 juni 2004 @ 23:11:
(Wat doe je als er in 1 methode meerdere null-pointer-exceptions kunnen voorkomen, hoe weet je waar het fout is gegaan?)

Daar heb je iets voor wat in de volksmond een "debugger" heet, gaat vaak gepaard met een zogenaamde "call stack". Zoek maar eens een keertje op.

[Daedalus]

Dit is een probleem waar ik al een tijd tegen aanloop. Ons is geleerd om bij elke methode de pre- en postcondities op te geven. De aanroepende methode moet zich daar dan aanhouden. Je zoud dus als aangeroepde methode dus kunnen verwachten dat de argumenten die je meekrijgt, kloppen.

Alleen ben ik met dit idee niet echt blij, omdat je nu afhankelijk ben van de grillen van de aanroepende methode en die wellicht weer afhankelijk is van een andere aanroepende methode. Ik denk daarom dat je zeker zeer streng moet zijn bij de controle van de argumenten, om zo inconsistentie van de data te voorkomen. Je gaat geen half werk afleveren. Je doet het of je doet het niet.

Dan is natuurlijk weer niet de bedoeling dat je op elk niveau de data gaat controleren. Daarom op het laagste niveau, zoals bij mutator-methoden. Het mooie wat ik van Java vind is dat je gewoon een complete stacktrace krijgt van waar het mis is gegaan. Ik ben nu bezig met ASP en VBScript en daar mis ik dat toch wel. Als het daar namelijk ergens fout gaat, dan krijg je alleen de regel zien waar het echt compleet fout ging. En dit is meestal in een algemene library, waar je dus geen ruk aan hebt.

[Soultaker]

Verwijderd schreef op 02 juni 2004 @ 23:30:
Ik betwijfel of iemand die praat over 'de exception-crap' uberhaupt ooit een groot project heeft moeten onderhouden, want code geschreven volgens het recept wat hij hierboven weergeeft is domweg ononderhoudbaar.

Voor zover ik weet werkt een groot deel van de applicaties geschreven in C met return values die aangeven of een call succesvol was. In ieder geval de API's van besturingssystemen als UNIX en Linux werken zo. Bovendien werken ook veel applicaties geschreven in C++ werk(t) op die manier (vaak omdat het lastig is om exceptions over process boundaries te gooien). Het is dus een beetje onzinnig om te doen alsof dat volslagen krankzinnig is.

De discussie is trouwens niet of exceptions beter zijn dan error checking door middel van return values, maar hoe 'streng' je moet zijn bij het checken van invoer en het raisen van exceptions.

Zelf controleer ik invoer van functies liever niet, behalve als het 'grote' functies zijn die onderdeel zijn van een publieke API. De reden hiervoor is dat een programma bestaat uit een heleboel function calls; argumenten voor de main functie worden weer gebruikt als argumenten voor function calls vanuit main, die weer worden gebruikt als argumenten in andere function calls. Als al deze functies hun argumenten valideren, dan doe je dus een heleboel werk, dat allemaal overbodig was als een waarde al geldig was toen 'ie voor het eerst gebruikt werd. Zulke code komt heel vaak voor in C programma's die aan alle functies in een library een context pointer meegeven die dan niet NULL mag zijn ofzoiets.

Een correct geschreven programma zorgt ervoor dat 'ie geldige argumenten aanbiedt aan functies. Die functies zijn niet voor niets gedocumenteerd (toch?). Dat is het contract tussen aanbieder en gebruiker van een functie. De aanbieder kan wel gaan checken of de gebruiker de functie goed gebruikt (en dat is natuurlijk 'lief') maar het directe gevolg is dat de performance eronder leidt. Dat is die error checking me niet waard! Checks en exceptions bewaar ik dan liever voor zaken waarvan bekend is dat ze kunnen falen, zoals bijvoorbeeld het openen van een bestand, waarop natuurlijk wel gecontroleerd moet worden. Omgekeerd doe ik hetzelfde, trouwens: als een random number generator zegt een getal tussen 0 en 10 te genereren, dan ga ik niet at runtime checken of het getal toevallig buiten de range ligt.

Assertions zijn om diezelfde reden superhandig; je krijgt het beste van de twee werelden. In een debug build kun je allerlei error checking uitvoeren en daarmee fouten in aanroepende applicaties vinden, maar in release mode zit je niet met de overhead ervan opgescheept.

[Soultaker]

Daedalus schreef op 02 juni 2004 @ 23:46:
Alleen ben ik met dit idee niet echt blij, omdat je nu afhankelijk ben van de grillen van de aanroepende methode en die wellicht weer afhankelijk is van een andere aanroepende methode. Ik denk daarom dat je zeker zeer streng moet zijn bij de controle van de argumenten, om zo inconsistentie van de data te voorkomen. Je gaat geen half werk afleveren. Je doet het of je doet het niet.

Dan is natuurlijk weer niet de bedoeling dat je op elk niveau de data gaat controleren. Daarom op het laagste niveau, zoals bij mutator-methoden. Het mooie wat ik van Java vind is dat je gewoon een complete stacktrace krijgt van waar het mis is gegaan.

Er is een goed software engineering gezegde: GARBAGE IN, GARBAGE OUT. Als je ongeldige argumenten aanbiedt, garandeer ik niet dat mijn functie correct werkt. Omwille van de performance en de simpliciteit van de code, vind ik dus juist dat je moet controleren op het allerhoogste nivo: zodra de gebruiker zijn leeftijd invoert, controleer je of die toevallig negatief is, niet pas als je de leeftijd als argument gebruikt in een berekening.

[Verwijderd]

Soultaker schreef op 02 juni 2004 @ 23:46:
Het is dus een beetje onzinnig om te doen alsof dat volslagen krankzinnig is.

Zijn recept behelst meer dan alleen het niet raisen van exceptions. Daar reageerde ik op, niet zozeer over of hij al dan niet exceptions raised.

Het enige wat ik op je argumentatie kan zeggen is: ik hoop dat ik jouw code nooit hoef te onderhouden.

Ja. Garbage in=garbage out, tot zover ben ik het met je eens. Net zoals dat ik het met je eens ben dat een goed programma een object/klasse/methode geen garbage aanbiedt.

Garbage in = error out lijkt me nog beter

Echter als de app. in kwestie oorspr. door iemand anders ontwikkeld is, kun je als ontwikkelaar wel eens niet 100% thuis zijn in het achterliggende model, en domweg een fout maken. Dan is het wel verdomde handig als je app waarschuwt, en niet gewoon jouw crappy invoer vertaalt in de verwachte integer.

[ Voor 51% gewijzigd door Verwijderd op 02-06-2004 23:55 ]

[Grijze Vos]

Amras schreef op 02 juni 2004 @ 23:31:
[...]


Zou je dit iets uit kunnen leggen? Vat hem niet helemaal...

Simpel voorbeeld.

de functie, in een c-achtige pseudo code

code:

addone(x : int)
{
   return x+1;
}

Dan kun je bewijzen dat met de invoer van een variabele N, de waarde N+1 eruit komt.
Uiteraard heb je 'in het echie' meestal niet zo'n eenvoudige methodes.

[Verwijderd]

.oisyn schreef op 02 juni 2004 @ 23:36:
[...]


Daar heb je iets voor wat in de volksmond een "debugger" heet, gaat vaak gepaard met een zogenaamde "call stack". Zoek maar eens een keertje op.

Dankje oisyn...

[Soultaker]

Verwijderd schreef op 02 juni 2004 @ 23:51:
Zijn recept behelst meer dan alleen het niet raisen van exceptions. Daar reageerde ik op, niet zozeer over of hij al dan niet exceptions raised.

Ik heb nog geen inhoudelijke reactie gezien hoor.

Het enige wat ik op je argumentatie kan zeggen is: ik hoop dat ik jouw code nooit hoef te onderhouden

Zelfde probleem: inhoudelijke reactie?

Echter als de app. in kwestie oorspr. door iemand anders ontwikkeld is, kun je als ontwikkelaar wel eens niet 100% thuis zijn in het achterliggende model, en domweg een fout maken. Dan is het wel verdomde handig als je app waarschuwt, en niet gewoon jouw crappy invoer vertaalt in de verwachte integer.

Je kunt als ontwikkelaar van bv. een library praktisch niet garanderen dat je alle manieren van foutief gebruik afvangt en als je dat wel doet dan heb je een matig presterende library gemaakt. Als iemand de moeite neemt om je code correct te gebruiken, dan verlies je het op performance van de concurrent. Gelukkig kun je het model wel goed documenteren, met pre- en postcondities en inclusief eisen aan de argumenten. Ik merk in de praktijk ook dat ik veel liever werk met libraries die in de documentatie zetten hoe je ze moet gebruiken, dan libraries met beperkte documentatie (ik noem geen namen, maar ik denk aan Japanners ) waarbij de enige indicatie dat je een library wel eens goed bezig zou kunnen gebruiken bestaat uit het feit dat je geen exceptions krijgt. Exceptions zijn geen alternatief voor documentatie!

Natuurlijk kun je assertions gebruiken om de gebruiker te ondersteunen (los van de documentatie) maar checks op argumenten horen naar mijn mening niet in release builds thuis.

[Amras]

Grijze Vos schreef op 02 juni 2004 @ 23:54:
[...]

Simpel voorbeeld.

de functie, in een c-achtige pseudo code

code:

addone(x : int)
{
   return x+1;
}

Dan kun je bewijzen dat met de invoer van een variabele N, de waarde N+1 eruit komt.
Uiteraard heb je 'in het echie' meestal niet zo'n eenvoudige methodes.

Aha, duidelijk

Maar zoals je al zegt is dat op complexere methodes een stuk ingewikkelder dan even een assert op de invariant en precondities. Wel interessant trouwens, heb het pdfje was Glimi linkte even gedownload. Zal het ooit eens doornemen.

[curry684]

Soultaker schreef op 02 juni 2004 @ 23:50:
[...]

Er is een goed software engineering gezegde: GARBAGE IN, GARBAGE OUT.

Dat gezegde ken ik vanzelfsprekend, maar gelukkig alleen over testcode en andere niet permanente code. Van de Win32 API ben ik bijvoorbeeld heel blij dat ze het GIEO (Garbage In, Error Out) concept aanhouden, in plaats van dat ik malformed windows all over the place krijg en m'n computer plat ga bij een foutje in een parameter. Op dezelfde manier programmeer ik zelf: als ik een functie schrijf die een foutconditie tegenkomt, gooi ik een exception. Niet omdat ik het zelf als implementer nodig heb, maar omdat over een half jaar iemand anders op het project zit om die code te onderhouden en ik dan niet dezelfde doodsverwensingen naar m'n hoofd wil krijgen als ik nu dagelijks naar diverse voorgangers moet uiten.

[.oisyn]

Grijze Vos schreef op 02 juni 2004 @ 23:54:
Dan kun je bewijzen dat met de invoer van een variabele N, de waarde N+1 eruit komt.

En als je er nou 2147483647 in stopt?

[Verwijderd]

Wat ik bedoel is dat IMHO een stuk code alleen verantwoordelijk is en mag zijn voor zijn eigen functioneren. Als ik een methode schrijf en die aanroep moet die methode niet ineens eigenwijs gaan doen en exceptions geven dat het wel eens fout zou kunnen gaan.

Dat is de verantwoordelijkheid van de bovenliggende code (juiste inputs en logisch correcte code).

/me oordeeld misschien niet juist vanwege de in zijn ogen arrogante manier waarop hij door de java-compiler benaderd wordt tav exceptions.

[ Voor 17% gewijzigd door Verwijderd op 03-06-2004 00:09 ]

[Infinitive]

En als je er nou 2147483647 in stopt?

Nou niet op de technische details gaan hameren he?
Als hij ook het domein had meegenomen in zijn voorbeeld, dan had het je aandacht afgeleid van het algemene idee.

[ Voor 78% gewijzigd door Infinitive op 03-06-2004 00:08 ]

[Glimi]

.oisyn schreef op 03 juni 2004 @ 00:03:
En als je er nou 2147483647 in stopt?

Het is bewezen voor een pseudo-taal welke die beperking niet heeft. Dat C alleen in dat domein werkt, maakt het bewijs niet minder valide. Je hebt het immers bewezen voor een sterkere preconditie

[ Voor 12% gewijzigd door Glimi op 03-06-2004 00:08 ]

[curry684]

Verwijderd schreef op 03 juni 2004 @ 00:05:
Wat ik bedoel is dat IMHO een stuk code alleen verantwoordelijk is en mag zijn voor zijn eigen functioneren. Als ik een methode schrijf en die aanroep moet die methode niet ineens eigenwijs gaan doen en exceptions geven dat het wel eens fout zou kunnen gaan.

Dat is de verantwoordelijkheid van de bovenliggende code (juiste inputs en logisch correcte code).

Ergo je doet nergens errorchecking. De user zelf is tenslotte bovenliggende inputter van je UI-laag, en is dus ervoor verantwoordelijk dat ie altijd geldige data invoert en correct geformatteerde files aanlevert. Je hoeft dus nergens wat voor input dan ook te controleren.

Snelle code schrijf jij zeker

[Verwijderd]

Wat veel belangrijker is, is om een foutieve invoer al voor te zijn. Als een gebruiker van je applicatie het voor elkaar krijgt om een foutieve datum in te geven, dan is het verstandig om eens te kijken naar je presentatie

[Verwijderd]

curry684 schreef op 03 juni 2004 @ 00:08:
[...]

Ergo je doet nergens errorchecking. De user zelf is tenslotte bovenliggende inputter van je UI-laag, en is dus ervoor verantwoordelijk dat ie altijd geldige data invoert en correct geformatteerde files aanlevert. Je hoeft dus nergens wat voor input dan ook te controleren.

Snelle code schrijf jij zeker

vaak wel maar ik check wel voor errors. tenminste op de plaatsen waar de loop van het programma verandert.

[.oisyn]

Glimi schreef op 03 juni 2004 @ 00:07:
[...]

Het is bewezen voor een pseudo-taal welke die beperking niet heeft. Dat C alleen in dat domein werkt, maakt het bewijs niet minder valide. Je hebt het immers bewezen voor een sterkere preconditie

Als jij serieus gaat mierenneuken kan ik dat ook: het is geen beperking van C, maar van het onderliggende platform. Het is namelijk niet gedefinieerd hoe groot een int is, het is slechts gedefinieerd dat een int grotergelijk dan short en kleinergelijk dan long is.

[Verwijderd]

.oisyn schreef op 03 juni 2004 @ 00:11:
[...]


Als jij serieus gaat mierenneuken kan ik dat ook: het is geen beperking van C, maar van het onderliggende platform. Het is namelijk niet gedefinieerd hoe groot een int is, het is slechts gedefinieerd dat een int grotergelijk dan short en kleinergelijk dan long is.

Was het bereik van de unsigned int niet gelijk aan de maximale waarde van de woordbreedte van de betreffende CPU? (32-bits op 32-bits processoren, 16 bits op 16-bits processoren, 8...)

[Soultaker]

.oisyn: maar het is gegarandeerd dat sizeof(int) een eindig getal retourneert. Derhalve heeft int ook maar een eindige precisie, dus ongeacht het platform is er een int X waarvoor X+1 niet meer te representeren is in een int.

[Verwijderd]

Soultaker schreef op 02 juni 2004 @ 23:58:
Ik heb nog geen inhoudelijke reactie gezien hoor.

Je bedoelt te zeggen dat je nog geen reactie hebt gezien die in jouw ogen als inhoudelijk gezien kan worden. Want hetgeen waar je verder op reageert was de inhoudelijke reactie.

Je kunt als ontwikkelaar van bv. een library praktisch niet garanderen dat je alle manieren van foutief gebruik afvangt en als je dat wel doet dan heb je een matig presterende library gemaakt. Als iemand de moeite neemt om je code correct te gebruiken, dan verlies je het op performance van de concurrent.

Dat is alleen van toepassing bij applicaties waarbij performance een hekel punt is. Volgens mij zijn 90% van de in NL ontwikkelde applicaties gewoon kantoorapplicaties waarin performance niet zo'n groot issue is. Daarnaast betwijfel ik ten zeerste of dit je app dermate vertraagt dat de eindgebruikers het merken, maar dat hangt natuurlijk wel sterk van je app af.

Exceptions zijn geen alternatief voor documentatie!

Andersom ook niet hoor. Documentatie is ook geen alternatief voor exceptions. Het zijn beide verschillende begrippen en imo beide noodzakelijk wil je een professioneel product afleveren (dit hangt natuurlijk wel een beetje van je product af, een 1+1 app hoeft niet zoveel documentatie bij uiteraard).

Natuurlijk kun je assertions gebruiken om de gebruiker te ondersteunen (los van de documentatie) maar checks op argumenten horen naar mijn mening niet in release builds thuis.

Dat hangt imo van de taak van de release build af. In het patienten-systeem van een ziekenhuis zou ik wel degelijk willen checken op argumenten.

Niet gebruiken van exceptions is imo er van uit gaan dat:

a) de computer naar behoren functioneert
b) de code naar behoren functioneert
c) de user naar behoren functioneert

Nu kun je b en c nog dismissen (code goed testen, user opvoeden) maar a niet imo.

[Glimi]

.oisyn schreef op 03 juni 2004 @ 00:11:
[...]Als jij serieus gaat mierenneuken kan ik dat ook:

Gezellige instelling .oisyn. Jammer alleen dat jouw punt niets afdoet aan mijn verhaal. Of je nou C vervangt door platform, het maakt allemaal niets uit.
Het wrappen van de int is echter een ander verhaal.

[ Voor 20% gewijzigd door Glimi op 03-06-2004 00:18 ]

[curry684]

Verwijderd schreef op 03 juni 2004 @ 00:14:
[...]

c) de user naar behoren functioneert

Dat doet de user nooit, users doen per definitie alles fout op de verkeerde manier op het foute moment helaas.... * curry684 zou ze graag afschaffen, eindgebruikers

[Verwijderd]

/me vraagt zich af of zijn aversie tegen 'exceptions' teoprecht is of dat dit alleen komt door de manier waarop java ze gebruikt.

/me gaat ff kijken hoe dat in c++ gaat

curry684 schreef op 03 juni 2004 @ 00:19:
[...]

Dat doet de user nooit, users doen per definitie alles fout op de verkeerde manier op het foute moment helaas.... * curry684 zou ze graag afschaffen, eindgebruikers

/me pakt schaar
/me knipt 3 draadjes door (monitor / muis / keyboard)

consider eindgebruiker removed

[ Voor 65% gewijzigd door Verwijderd op 03-06-2004 00:22 ]

[Soultaker]

Verwijderd schreef op 03 juni 2004 @ 00:14:
Niet gebruiken van exceptions is imo er van uit gaan dat:

a) de computer naar behoren functioneert
b) de code naar behoren functioneert
c) de user naar behoren functioneert

Nu kun je b en c nog dismissen (code goed testen, user opvoeden) maar a niet imo.

Ik denk eerder dat je alleen optie c niet kunt dismissen. Je moet daarom invoer van de gebruiker (en van externe bronnen als andere processen, databestanden, netwerkverbindingen, etcetera) niet vertrouwen en de invoer daarvan controleren.

Op punt a ben ik duidelijk van mening dat je er van uit mag gaan dat de computer naar behoren functioneert. Hoe kun je anders ooit nog een correct programma schrijven? Controleer jij of gegevens die je naar het geheugen schrijft er later ongewijzigd weer uitkomen? Ik denk het niet, want het kan ook helemaal niet. De enige manier om toch geheugen te kunnen gebruiken is aan te nemen dat het geheugen correct werkt en in bedrijfskritieke situaties de kans daarop te vergroten door bijvoorbeeld ECC geheugen te gebruiken.

[Verwijderd]

Verwijderd schreef op 03 juni 2004 @ 00:20:
consider eindgebruiker removed

En in jouw geval komt ie daar nooit achter, want hij krijgt geen enkele foutmelding of wat dan ook.. Als hij in apparaatbeheer kijkt staat er bij het tobo: this device is functioning correctly oid.

[Daedalus]

Soultaker schreef op 02 juni 2004 @ 23:50:
[...]

Er is een goed software engineering gezegde: GARBAGE IN, GARBAGE OUT.

Ik vind dit zelf een zeer slechte gezegde, mede door de redenen die curry684 aangeeft. Misschien komt het doordat ik voornamelijk ervaring heb met het programmeren in Java en daardoor het mechanisme van Excepties gewend ben, die misschien niet in andere programmeertalen aanwezig is.

Dan nog over waar je dan de invoer met controleren. Bij data zoals leeftijd is het misschien overkill om dat in de mutator-methodes te doen en misschien beter om dit op UI niveau te doen, mede doordat een variable zoals leeftijd een redelijk vast domein heeft.

Dit kan je echter ook beperkingen opleveren voor toekomstige aanpassingen. Als bijvoorbeeld de pre-condities van een complexe klasse veranderen waardoor er een breder domein aan invoer mogelijk is, zit je met de beperkingen die de UI oplegt. Die zal je dan ook moeten aanpassen op UI niveau en misschien ook wel op andere plekken in de code. Het komt de onafhankelijkheid van de klasse niet ten goede.

Wellicht dat deze ideeen alleen toepasbaar zijn bij object-georienteerde programmeertalen, maar dat krijg je als er in je opleiding voornamelijk object-georienteerde talen en software engineering wordt gegeven

[Infinitive]

Waarom zou je dan een Exception slecht vinden? Een exception kan je zien als "uber" foutmelding. Het bevat een beschrijving van wat mis ging, de exacte lokatie waar het mis ging. Verder kan je exceptions groeperen en stapelen.

Omdat foutcodes bovendien functieabstractie verpesten, is het "return" mechanische gebruiken niet handig. Vandaar: extra syntax (try/catch) zodat dat nog gewoon kan.

Bovendien krijg je als je een beetje slordig programeerd typisch iets als:

code:

if (functie1() < 0) { delete bla; delete bla2; return -1 }
if (functie2() < 0) { delete bla; delete bla2; return -1 }
if (functie3() < 0) { delete bla; delete bla2; return -1 }
if (functie4() < 0) { delete bla; delete bla2; return -1 }
if (functie5() < 0) { delete bla; delete bla2; return -1 }
if (functie6() < 0) { delete bla; delete bla2; return -1 }
if (functie7() < 0) { delete bla; delete bla2; return -1 }

Terwijl je in dit geval ook iets kan doen als:

code:

try { functie1(); functie2(); functie3(); ... }
finally { delete bla; delete bla2 }

Trouwens, waarom doen compilers zo "weinig" aan statische checks? Ik heb nog geen compiler gezien die mij een waarschuwing geeft als ik opschrijf:

code:

int[] a = { 1, 2, 3 }
for(int i=0; i < 4; i++)
   print a[i];

of:

code:

int x=3; int y=0; return x/y;

Maar in hoeverre moet je lief zijn en in hoeverre streng?

Zijn er ook nadelen voor streng zijn? Als je het de moeite waard vind om zo'n test in te bouwen zie ik verder geen reden om dat wel te doen.
Nou ja, misschien toch wel één: als mensen gewend zijn dat in bepaalde gevallen geen strenge controle wordt gedaan. Bijvoorbeeld bij het verwijderen van een listener kan je denken: "waarom zou het verwijderen van een listener een probleem zijn. Als 'ie er niet is dan is het makkelijk weggooien.". En stel dat nu alle vergelijkende softwarepakketen daar geen exceptie gooien. Wie zullen er dan gaan vloeken als ze voor het eerst jouw bibliotheek gebruiken (maar ok, is dan ok eigen schuld voor het niet lezen van de documentatie)

[ Voor 45% gewijzigd door Infinitive op 03-06-2004 00:46 ]

[joepP]

Ik ben ook van het harde werk. Een foute invoer = een exception. Streng doch rechtvaardig. Probeer maar eens een programma (of library!) te debuggen die geen exceptions raised, maar gewoon zelf wat gaat zitten aannemen. Je krijgt dan de vreemdste fouten, waarbij je ettelijke uren kwijt bent aan debugging. Als er direct bij de bron een exception zou optreden, had je deze fout in een minuut gefixed.

Nog erger wordt het als het een zeldzame fout is in het wild. Dus niet mooi achter je eigen machine, maar alleen bij de klant. Het wordt dan bijna onmogelijk om nog iets te achterhalen zonder exceptions, uiteraard met call-stack.

Dit gaat natuurlijk niet op voor code waarbij performance echt alles uitmaakt. Maar ik denk dat de overhead van wat checking voor 99,9% van de applicaties verwaarloosbaar is, of niet terzake doet.

(Enne, ik ben nu in Java bezig. Helaas... Hoe ze je daar dwingen om elke exception te try-catchen is echt uberzielig)

[Verwijderd]

Soultaker schreef op 03 juni 2004 @ 00:25:
Ik denk eerder dat je alleen optie c niet kunt dismissen. Je moet daarom invoer van de gebruiker (en van externe bronnen als andere processen, databestanden, netwerkverbindingen, etcetera) niet vertrouwen en de invoer daarvan controleren.

Ik bedoelde het denk ik anders dan jij het leest. Ik bedoelde dat voor het controleren van userinvoer niet perse van exceptions gebruik gemaakt hoeft te worden. De user opvoeden kan de applicatie zelf. Voor de user lijkt het dan alsof hij een foutmelding voor z'n keizen krijgt, maar voor de app is het gewoon een schermpje.

Een wat prutserig voorbeeld hiervan is:

Delphi:

if edNaam.Test='' then 
    MessageDlg('vul een naam in sukkel', mtWarning, [mbOk],0)
  else
      begin
        oUser.Naam:=edNaam.Test;
        oUser.save;
      end;

Ik zou dit nooit op deze manier doen, maar iemand die nooit exceptions gebruikt zal dit soort noodgrepen wel moeten gebruiken, met ellenlange if .. then constructies als resultaat, of allerlei nare instructies als break of exit.

Maar goed, het werkt wel. Als de user een lege naam invult, wordt er niets opgeslagen.

Vandaar dat je die binnen de exceptions-discussie imo kunt dismissen, je hebt niet perse exceptions nodig om de user te dwingen het juiste in te vullen.

Met 'de computer functioneert' bedoel ik het geheel, de samenvatting van hard en -software. Er zijn meer redenen mogelijk waarom informatie op een bepaalde geheugenplaats niet vertrouwd zou kunnen worden dan louter hardwarematige.

//edit
je hebt gelijk als je zegt dat je daarmee de fout niet voorkomt. Daar gaat het niet zozeer om, waar het om gaat is dat je app deze fout wel moet kunnen registreren, of igg. voor zover mogelijk.

Een grof voorbeeld hiervan.. Windows BSOD'd wel eens terwijl dit strict genomen niet nodig was, de kernel zelf draaide nog op dat moment. Op zo'n moment is een dermate kritieke fout opgetreden (hetzij in de code, hetzij in de 'computer') dat ze de werking van het OS niet meer te vertrouwen achten, en daarom geven ze een BSOD.

Dit is een beetje analoog aan een exceptie. Het altijd iets retourneren zonder exceptie komt binnen deze analogie gelijk aan het volledig weglaten van dit BSOD.

Stel je hebt een HD-crash. Windows kan niet meer schrijven naar de HD, maar in principe weerhoudt dat het OS er niet van te functioneren. Jouw Word schrijft zo af en toe het document waar je mee bezig bent weg naar je harde schijf, althans dat denkt ie want de schrijf() functie van het OS retourneerd gewoon een 0 oid.

enzovoort.

[ Voor 26% gewijzigd door Verwijderd op 03-06-2004 00:55 ]

[.oisyn]

Verwijderd schreef op 03 juni 2004 @ 00:13:
[...]


Was het bereik van de unsigned int niet gelijk aan de maximale waarde van de woordbreedte van de betreffende CPU? (32-bits op 32-bits processoren, 16 bits op 16-bits processoren, 8...)

Heb het nog eens nagezocht, er is slechts gedefinieerd dat een (unsigned) int minimaal 16 bits is, er wordt niets gezegd over de word-grootte van de CPU. Een praktijkvoorbeeld hiervan is bijvoorbeeld het Win64 platform, waar een int nog altijd slechts 32 bits is (de long schaalt echter wel mee naar 64).

Soultaker schreef op 03 juni 2004 @ 00:14:
.oisyn: maar het is gegarandeerd dat sizeof(int) een eindig getal retourneert. Derhalve heeft int ook maar een eindige precisie, dus ongeacht het platform is er een int X waarvoor X+1 niet meer te representeren is in een int.

waar

Glimi schreef op 03 juni 2004 @ 00:15:
[...]

Gezellige instelling .oisyn.

Uhm, dat geldt voor jouw opmerking net zo goed. Ik maak gewoon een losse niet-serieuze opmerking, jij meent daar bloedserieus op in te gaan door mij te verbeteren. Dat doe ik ook, en dan ga jij een beetje "beledigd" zitten doen? Had ik er dan een smile achter moeten zetten, eentje die jij in dat geval net zo goed vergeten was? Til er alsjeblieft niet zo zwaar aan. Gezelligheid komt van 2 kanten, ik mis 'm alleen van jou kant nog

[ Voor 4% gewijzigd door .oisyn op 03-06-2004 00:53 ]

[Soultaker]

Verwijderd schreef op 03 juni 2004 @ 00:39:
Met 'de computer functioneert' bedoel ik het geheel, de samenvatting van hard en -software. Er zijn meer redenen mogelijk waarom informatie op een bepaalde geheugenplaats niet vertrouwd zou kunnen worden dan louter hardwarematige.

Hoe controleer je die dan?

Mijn punt is je toch wat moet aannemen om ueberhaupt een programma af te krijgen. Dat is ook de opzet van het dit topic, geloof ik: waar ligt de grens tussen wat je moet controleren en wat je aan mag nemen. Heldere en efficiente code maakt volop gebruik van aannames met betrekking tot de werking van de hardware, het besturingssystem, en de werking van andere applicaties. Altijd alles willen controleren is mooi, maar niet praktisch. Dat zie je trouwens overal terug, niet alleen in software engineering.

[.oisyn]

Infinitive schreef op 03 juni 2004 @ 00:32:
Bovendien krijg je als je een beetje slordig programeerd typisch iets als:

code:

if (functie1() < 0) { delete bla; delete bla2; return -1 }
if (functie2() < 0) { delete bla; delete bla2; return -1 }
if (functie3() < 0) { delete bla; delete bla2; return -1 }
if (functie4() < 0) { delete bla; delete bla2; return -1 }
if (functie5() < 0) { delete bla; delete bla2; return -1 }
if (functie6() < 0) { delete bla; delete bla2; return -1 }
if (functie7() < 0) { delete bla; delete bla2; return -1 }

Terwijl je in dit geval ook iets kan doen als:

code:

try { functie1(); functie2(); functie3(); ... }
finally { delete bla; delete bla2 }

Ja maar dat kan zonder exceptions natuurlijk net zo goed door al die functies in die if () te gooien (of in een array die je dan doorloopt)

Trouwens, waarom doen compilers zo "weinig" aan statische checks? Ik heb nog geen compiler gezien die mij een waarschuwing geeft als ik opschrijf:

code:

int[] a = { 1, 2, 3 }
for(int i=0; i < 4; i++)
   print a[i];

of:

code:

int x=3; int y=0; return x/y;

VS.Net Whidbey gaat dat dus wel doen

Zijn er ook nadelen voor streng zijn? Als je het de moeite waard vind om zo'n test in te bouwen zie ik verder geen reden om dat wel te doen.

Ligt er een beetje aan. Ten eerste natuurlijk sowieso performance (in een game ga je bijvoorbeeld echt geen condities controleren), maar exceptions kunnen behoorlijk vervelend zijn als je niet geinteresseerd bent in foutmeldingen. Het On Error Resume Next principe zeg maar, dat is alleen te doen door elke statement afzonderlijk in een try-catch block te gooien. Ook de reden waarom ik geen exception gegooid wil zien als je een string die geen int is naar een int probeert te converteren (return maar lekker 0, je kunt het altijd nog valideren als je dat echt nodig hebt), of idd dat als je iets uit een lijst verwijderd wilt hebben wat er niet eens in voorkomt. Vooral dat laatste is typisch iets waarin je niet geinteresseerd bent. Net als dat je in C++ prima delete kunt aanroepen op een nullpointer.

[ Voor 13% gewijzigd door .oisyn op 03-06-2004 01:05 ]

[Verwijderd]

Soultaker schreef op 03 juni 2004 @ 00:51:
Mijn punt is je toch wat moet aannemen om ueberhaupt een programma af te krijgen. Dat is ook de opzet van het dit topic, geloof ik: waar ligt de grens tussen wat je moet controleren en wat je aan mag nemen. Heldere en efficiente code maakt volop gebruik van aannames met betrekking tot de werking van de hardware, het besturingssystem, en de werking van andere applicaties. Altijd alles willen controleren is mooi, maar niet praktisch. Dat zie je trouwens overal terug, niet alleen in software engineering.

Tsja in de praktijk hangt het natuurlijk ook van het budget en de doorlooptijd af, dat weet ik ook wel.

Er zit nogal een verschil tussen 'altijd alles controleren' en 'niets controleren', of 'niets controleren behalve userinput'.

De eerste ('altijd alles controleren') is imo het ideaal, maar domweg niet altijd haalbaar. Het 2e staat loodrecht op dit ideaal, en het derde maakt nog een dermate grote hoek dat ik mij er niet in kan vinden.

[ Voor 3% gewijzigd door Verwijderd op 03-06-2004 01:10 ]

[Soultaker]

Verwijderd schreef op 03 juni 2004 @ 00:39:
je hebt gelijk als je zegt dat je daarmee de fout niet voorkomt. Daar gaat het niet zozeer om, waar het om gaat is dat je app deze fout wel moet kunnen registreren, of igg. voor zover mogelijk.

Daar ben ik het helemaal mee eens en dat is ook niet in tegenspraak met wat ik zei. Fouten die intern optreden of kunnen optreden omdat niet gegarandeerd wordt dat ze niet optreden moeten altijd afgevangen en gerapporteerd worden. Dat is de enige manier waarop een applicatie zich aan z'n conceptuele 'contract' kan houden. Als Windows immers beweert dat een schrijf() operatie daadwerkelijk schrijft, dan kan het niet zo zijn dat dat een keer niet gebeurt. In de documentatie zal dus zoiets staan dat ofwel de data geschreven worden, ofwel dat er een fout wordt gerapporteerd. Zelfs als Windows niet kan schrijven, kan het systeem toch nog aan het contract voldoen. Daarbij wordt er van uitgegaan dat de harde schijf zich ook aan zijn contract houdt: als op de IDE bus het schrijven bevestigd is, moet dat ook daadwerkelijk gebeurd zijn; iets wat het besturingssysteem nauwelijks kan controleren.

Mijn enige punt hier is dat een functie niet meer aan zijn contract gehouden is wanneer de aanroeper zich daar ook niet aan houdt. Dat kan in veel gevallen ook niet, aangezien de correcte werking voor argumenten die buiten het contract vallen niet bekend is.

[Alarmnummer]

IK doe even mijn ogen dicht en dan zijn er meteen 3 pagnina`s bij gekomen!

De gebruiker moet idd zoveel mogelijk geholpen worden en foutmeldingen kunnen op 1001 manieren weergegeven worden. Maar het gaat met dus voornamelijk om de client-programmeur. Hoe ga ik die behandelen? Ga ik een foutmelding opwerpen als hij iets doet dat niet heel ernstig is (bv een listener removen die al niet meer aanwezig is) of ga verlaat je de methode netjes en doet alsof er niets aan de hand was. Tenslotte staat het systeem nu niet in een inconsistente toestand.

Sun is in zijn libraries redelijk vergevingsgezind en ik ben een beetje van de strenge stempel puur en alleen om bugs van mezelf te vinden. Maar aan de andere kant krijg ik zelf in final releases wel eens exceptions voor de kiezen die dodelijk waren en je applicatie doet precies het gene wat je met die strenge aanpak probeerde te verhelpen. De oplossing is dus zelf het probleem geworden.

Verder merk ik dat er commentaar komt op allerlei zaken zoals exception en dat mensen dit topic daar weinig ervaring mee hebben gehad. Exceptions zijn super krachtig, je hoeft je return waardes er niet mee te verneuken, en verder je kunt ook gebruik maken van unchecked exceptions. Het is bij mij echt een zeldzaamheid dat ik zelf nog een checked exception schrijf en de keren dat het moet komen me ze (meestal) goed uit.

[ Voor 6% gewijzigd door Alarmnummer op 03-06-2004 07:02 ]

[Ximinez]

curry684 schreef op 02 juni 2004 @ 23:18:
[...]

Oh my god, ik zie dat je nog aan je opleiding bezig bent.... ik hoop echt dat je nog een paar dingen leert voordat ze jou op de arbeidsmarkt loslaten, want nu ben je levensgevaarlijk voor eender welk project...

Dat is nu precies wat er mis is met de arbeidsmarkt. Het feit dat men zich niet bezighoud met het schrijven van gevalideerde code. Het gebruik van assertions is iets wat iedereen zou moeten doen. Design by Contract zorgt ervoor dat juist voordat men aan het kloppen slaat eerst nadenkt en niet achteraf fouten gaat herstellen die voorkomen hadden kunnen worden. Als men wat meer oog voor kwaliteit heeft en minder denkt aan achteraf uurtje faktuurtjes dan zou het een stuk beter worden. Iemand als curry684 zou ik direct uit mijn team verwijderen en vragen de concierge te gaan assisteren.

Overigens vind ik de oplossing van Alarmnummer niet goed aangezien Exceptions daar niet voor bedoeld zijn. Daarnaast achterhaal je de oorzaak niet. Betekend dus dat je post condities moet gaan testen want daar ligt de oorzaak van de fout.
In Java kan je assertions via een command line switch in/uit schakelen zodat je ze tijdens de ontwikkelfase gebruikt en tijdens productie weer uitzet.

Dan is er nog de techniek van crosscutting zoals AspectJ dat biedt. Daarmee kan je generiek een validatie model en exception handling model opzetten. Enfin er zijn meer wegen die naar Rome leiden.

Voor wie het interesseert, bestudeer de The Catalysis Approach. Hoewel ik deze methodiek te zwaar acht bevat het veel leerzame zaken. http://www.catalysis.org/

[Alarmnummer]

Ximinez schreef op 03 juni 2004 @ 07:42:
[...]
Overigens vind ik de oplossing van Alarmnummer niet goed aangezien Exceptions daar niet voor bedoeld zijn. Daarnaast achterhaal je de oorzaak niet.

Volgens mij begrijp jij het niet helemaal goed. Als je hier al bent gekomen, om wat voor reden dan ook (een niet goed validerende gui), dan heb je dus een probleem en dat probleem is zo ernstig dat je een exception opwerpt. Als jij namelijk geen exception opwerpt en bv een negatieve leeftijd aan een persoon kan koppelen, dan kan je dus rotte domein objecten krijgen. En ik hoef denk ik niet uit te leggen dat dat minder leuk is.

Exceptions zijn hier dus helemaal voor bedoelt.

Normale programflow hoor je niet te regelen met exceptions, maar een uitzonderlijke situaties moet je een exception kunnen opwerpen.

[ Voor 14% gewijzigd door Alarmnummer op 03-06-2004 07:59 ]

[Ximinez]

Alarmnummer schreef op 03 juni 2004 @ 07:57:
[...]

Normale programflow hoor je niet te regelen met exceptions, maar een uitzonderlijke situaties moet je een exception kunnen opwerpen.

Precies, het voorbeeld laat nu juist geen uitzonderlijke situatie zien. Namelijk de voorwaarde is bekend. Dus de implementatie kan rekening houden met die voorwaarde. Niet als gevolg van het afwijken van die voorwaarde zelf een exception genereren. Dat is wat ik bedoel met "Daar zijn Exception niet voor".

[Verwijderd]

Ximinez schreef op 03 juni 2004 @ 07:42:
[..]
Iemand als curry684 zou ik direct uit mijn team verwijderen en vragen de concierge
te gaan assisteren.

Ik denk dat je hier per ongeluk de verkeerde naam neergezet hebt. Curry684 vond juist wel dat zaken gecontroleerd moesten worden, en exceptions gebruikt waar nodig. Ik neem aan dat je psyBSD bedoelde, die anti-exceptions of welke vorm van errorchecking dan ook is.

Ik zie curry684 nergens zeggen dat ie tegen design by contract is.

[Janoz]

Ximinez schreef op 03 juni 2004 @ 08:05:
[...]


Precies, het voorbeeld laat nu juist geen uitzonderlijke situatie zien. Namelijk de voorwaarde is bekend. Dus de implementatie kan rekening houden met die voorwaarde. Niet als gevolg van het afwijken van die voorwaarde zelf een exception genereren. Dat is wat ik bedoel met "Daar zijn Exception niet voor".

dus? Het voorbeeld dat alarmnummer geeft betekend niet dat dit de enige plek is waar leeftijd wordt gecontroleerd? Zelfs met deze implementatie (met exception) kan en moet de implementerende applicatie rekening houden met de voorwaarden. Waneer deze daar niet in slaagt wordt er niet stilletjes overheen gestapt, maar gewoon duidelijk aangegeven dat er wat vergeten is. Niet alleen maakt dit het debuggen veel makkelijker, je kun ook de juistheid van je programma simpeler garanderen.

Of vind jij dat een div implementatie maar 0 terug moet geven waneer je als deler 0 opgeeft omdat duidelijk moet zijn dat div niet 0 als deler accepteerd?

[Donderwolk]

Alarmnummer schreef op 02 juni 2004 @ 21:47:
Hoe lief moet je zijn met het schrijven van je methodes? Ik heb er een enorme rothekel aan als ik methodes heb die geen foutmelding gegeven en er toch iets niet helemaal in de haak was:

code:

setLeeftijd(int leefijd){
     if(leeftijd<0)
          _leeftijd = 0;
     else
          _leeftijd = leeftijd;
}

Dit wil ik dus niet, ik wil gewoon een dikke foutmelding:

code:

setLeeftijd(int leefijd){
     if(leeftijd<0)
           throw new IllegalArgumentException("....");    
     _leeftijd = leeftijd;
}

Het hangt er bij mij meestal wat van af. Void's probeer ik iig zoveel mogelijk te voorkomen. Zo zou je bijvoorbeeld een boolean terug kunnen geven die aangeeft of iets is gelukt of niet zodat je een evt fout vrij snel kunt afvangen.

Is er geen ruimte voorhanden om een waarde terug te geven dan gooi ik liever ook met Errors.

code:

boolean setLeeftijd(int leefijd){
     if(leeftijd<0){
          _leeftijd = 0;
          return false;
     }
     else{
          _leeftijd = leeftijd;
          return true;
     }
}

[ Voor 28% gewijzigd door Janoz op 03-06-2004 09:33 ]

[Janoz]

Donderwolk schreef op 03 juni 2004 @ 09:24:
[...]


Het hangt er bij mij meestal wat van af. Void's probeer ik iig zoveel mogelijk te voorkomen. Zo zou je bijvoorbeeld een boolean terug kunnen geven die aangeeft of iets is gelukt of niet zodat je een evt fout vrij snel kunt afvangen.

Is er geen ruimte voorhanden om een waarde terug te geven dan gooi ik liever ook met Errors.

code:

boolean setLeeftijd(int leefijd){
     if(leeftijd<0){
          _leeftijd = 0;
          return false;
     }
     else{
          _leeftijd = leeftijd;
          return true;
     }
}

Wat voor voordeel heeft dit boven het gooien van een exception? Nadelen weet ik wel:
* Je weet niet wat er fout gegaan is
* Je code wordt minder goed leesbaar
* je zult, waneer je daadwerkelijk gegevens terug wilt geven, dit via een pass by ref methode moeten doen
* je kunt meerdere aanroepen van deze functie niet wrappen in 1 try catch statement.


Ja, ook moderators maken wel eens een vergissing tussen het edit en quote knopje, alleen heeft dat vervelendere gevolgen

[Donderwolk]

Janoz schreef op 03 juni 2004 @ 09:33:
[...]

Wat voor voordeel heeft dit boven het gooien van een exception? Nadelen weet ik wel:
* Je weet niet wat er fout gegaan is
* Je code wordt minder goed leesbaar
* je zult, waneer je daadwerkelijk gegevens terug wilt geven, dit via een pass by ref methode moeten doen
* je kunt meerdere aanroepen van deze functie niet wrappen in 1 try catch statement.


Ja, ook moderators maken wel eens een vergissing tussen het edit en quote knopje, alleen heeft dat vervelendere gevolgen

Ik heb ook geen idee wat het voordeel is maar ik vond het wel liev.
Zelf gooi ik ook liever met Errors hoor.

[bigbeng]

Tjeemig wat een lange post alweer. Ik wil ook nog even mijn twee cent kwijt en wel voornamelijk als reactie op de mensen die vinden dat Java teveel dwingt om met Exceptions te werken.

Ik ben het daar namelijk niet mee eens en wel om het volgende:
Je kunt heel simpel een try catch statement schrijven die alle exceptions opvangt en er vervolgens niks mee doet. Ik ben daar zelf niet zo'n voorstander van, maar als je brakke error-handling wilt, dan kun je het krijgen. Het kost je om precies te zijn 4 regels code extra, nl de try, de catch en de twee sluitaccolades van beide. Als je kunt accepteren dat je een methode perse met accolade openen en sluiten moet , dan moet die vier extra regels toch ook nog wel kunnen.

Ook wil ik even reageren op de mensen die iets zeggen over dat Exceptions een negatief effect hebben op performance, omdat er veel dubbelgecheckt wordt enzo. Performance is sowieso niet iets waar een compiled code interpreter als de JVM voor bedoeld is, hoewel je natuurlijk best nog wat aan je code kunt twieken om het beter te laten performen, zul je met native code (lees assembly of machinetaal) altijd betere performance halen. Helaas kost het kloppen van de code dan wel wat extra uurtjes, zeker als je meerdere hardware platforms wilt ondersteunen.
En ik heb persoonlijk het vermoeden dat de simpele try catch structuur zoals ik hierboven beschrijf door de compiler nog wel geoptimaliseerd wordt.

[ACM]

curry684 schreef op 02 juni 2004 @ 23:12:
[...]

Het argument dat een assertion sneller is dan een exception vind ik nogal bull in deze tijd van 10+ branch prediction pipelines en 3Ghz processors. De enige assertions die ik gebruik zijn static (compiletime) asserts, op runtime vind ik het gewoon ondingen. Kapotte code moet knallen, en niet alleen op debug build, al is het maar omdat je op releasebuilds juist tig keer gevoeliger bent voor data corruption.

Lees es wat beter ajb...

Mijn argument is dat ze met weinig performance verlies uit te schakelen zijn. Dus dat "performance verlies van checks" geen argument is om de debugcode in de vorm van assertions maar gewoon weg te laten. Op die manier zou je zelfs de release-build nog in "debug mode" kunnen draaien op het moment dat er een fout is ontdekt, maar tot die tijd gewoon in "standaard mode" draaien, waardoor e.e.a. wat vlotter verloopt.

Er staat nergens dat ze "sneller dan een exception" zijn, sterker nog in veel gevallen worden ze in de vorm van een exception uitgevoerd

Maar voor alles wat "niet hoort voor te komen" (omdat het al eerder afgevangen was of had moeten zijn bijvoorbeeld) hoef je, imho, niet perse nog uitgebreide controles in te bouwen in je code. Assertions zijn daar min of meer voor bedoeld. Checks dat een listener die al verwijderd is niet nog es wordt verwijderd lijkt me daar een aardig voorbeeld voor, hoewel het van de omstandigheden afhangt natuurlijk.

[ Voor 16% gewijzigd door ACM op 03-06-2004 10:30 ]

[curry684]

Ximinez schreef op 03 juni 2004 @ 07:42:
[...]

Iemand als curry684 zou ik direct uit mijn team verwijderen en vragen de concierge te gaan assisteren.

Gelukkig hoef je die kans niet te krijgen daar ik over het algemeen zelf in die verwijderpositie zit Maar ik ga er idd ook maar van uit dat mijn naam daar fout in gezet is

[whoami]

Verwijderd schreef op 03 juni 2004 @ 00:39:
[...]

Een wat prutserig voorbeeld hiervan is:

Delphi:

if edNaam.Test='' then 
    MessageDlg('vul een naam in sukkel', mtWarning, [mbOk],0)
  else
      begin
        oUser.Naam:=edNaam.Test;
        oUser.save;
      end;

Ik zou dit nooit op deze manier doen, maar iemand die nooit exceptions gebruikt zal dit soort noodgrepen wel moeten gebruiken, met ellenlange if .. then constructies als resultaat, of allerlei nare instructies als break of exit.

Hmmm.....
Je moet je wel realiseren dat het gooien van excepties duur is.
Om jouw voorbeeld er ff bij te nemen: voor zo een geval zou ik geen excepties gebruiken, maar wel degelijk een input validatie doen voordat de user gesaved wordt.

Excepties zijn een krachtige manier om onverwachte errors / input / whatever te vermelden en om ernaar te handelen.
Echter, imo mag je ze niet 'misbruiken' voor bepaalde dingen zoals input-controle oid.

Owja, het ging hier over 'vergevingsgezindheid' wb API's. Nuja, als er iets voorvalt dat niet kan kloppen / klopt, dan zou ik een exceptie gooien, en niet gewoon doorgaan alsof er niets aan de hand is.
Als je dat wel doet, doet me dat sterk denken aan:

code:

try
{
   ...
}
catch( Exception ex )
{
   // empty catch
}

[ Voor 16% gewijzigd door whoami op 03-06-2004 11:09 ]

[bigbeng]

whoami schreef op 03 juni 2004 @ 11:02:
[...]

Hmmm.....
Je moet je wel realiseren dat het gooien van excepties duur is.
Om jouw voorbeeld er ff bij te nemen: voor zo een geval zou ik geen excepties gebruiken, maar wel degelijk een input validatie doen voordat de user gesaved wordt.

Excepties zijn een krachtige manier om onverwachte errors / input / whatever te vermelden en om ernaar te handelen.
Echter, imo mag je ze niet 'misbruiken' voor bepaalde dingen zoals input-controle oid.

Aan de andere kant moet je er weer voor waken om aan de UI kant teveel business logic te stoppen, tenminste als je probeert (zo) netjes (mogelijk) n-tier te programmeren. Ik ben zelf een voorstander van domeinafbakening door de UI (dus een numeriek veld moet nummers bevatten en dergelijke), maar overige invoerfouten zou ik persoonlijk toch via Exceptions afhandelen.

[whoami]

bigbeng schreef op 03 juni 2004 @ 11:08:
[...]


Aan de andere kant moet je er weer voor waken om aan de UI kant teveel business logic te stoppen, tenminste als je probeert (zo) netjes (mogelijk) n-tier te programmeren. Ik ben zelf een voorstander van domeinafbakening door de UI (dus een numeriek veld moet nummers bevatten en dergelijke), maar overige invoerfouten zou ik persoonlijk toch via Exceptions afhandelen.

Idd, hier heb je wel gelijk.
Echter, je kan je afvragen of die (simpele) validatie bij de UI thuishoort, of bij de BL.

[sjaakaq]

Glimi schreef op 02 juni 2004 @ 23:33:
[...]

Leuke invalshoek.
Helaas gaat het hier over 'lief zijn tegen programmeurs'. Het gaat er namelijk om of je een programmeur extra veel werk wilt laten doen (veel try/catch statements voor alle mogelijke gevallen) of dat je meer risico neemt.

Het ging eigenlijk over lief zijn tegen de user van het programma

Maar ik kan me voortaan beter buiten P&W discussie houden

[Verwijderd]

Staat deze hele discussie niet aan de basis van de huidige problemen met buffer-overrunsexploits en dergelijke? Lief zijn op basis van gebruiksvriendelijkheid en snelheid lijkt mij hetzelfde als 120 rijden met een zeepkist: gaat allemaal fantastisch totdat je een obstakel tegenkomt...

[joepP]

whoami schreef op 03 juni 2004 @ 11:02:
[...]

Owja, het ging hier over 'vergevingsgezindheid' wb API's. Nuja, als er iets voorvalt dat niet kan kloppen / klopt, dan zou ik een exceptie gooien, en niet gewoon doorgaan alsof er niets aan de hand is.
Als je dat wel doet, doet me dat sterk denken aan:

code:

try
{
   ...
}
catch( Exception ex )
{
   // empty catch
}

Dit fijne voorbeeld is -precies- wat Java in de hand werkt door af te dwingen dat je alles catched. Toegegeven, het is een schandalige manier van werken, maar waarom wordt je in godsnaam gedwongen om alles af te vangen?

Voorbeeldje. Je schrijft een applicatie die iets moet berekenen, bijvoorbeeld een of ander obscuur algoritme. Je wil dit over een bepaalde dataset draaien, en daarna eigenlijk nooit meer. De code gaat niet commercieel, wordt niet niet eens openbaar, je gebruikt het alleen zelf, waarschijnlijk eenmalig.

Waarom wordt ik dan gedwongen bij elke file-access een exception af te vangen? Ik draai dat ding alleen lokaal, de harddisk is nog lang niet vol, en schrijfrechten heb ik ook. Ik wil dan helemaal niets catchen, gewoon een keiharde fout als het misgaat. Maar ja, als je ergens diep in je code wat file-access doet -moet- je wel lokaal afvangen. Terwijl het default Java-gedrag bij (bijvoorbeeld) een null-pointer-exception precies is wat ik wil als het misgaat...

En ja, ik ben lui

[Zoijar]

Bij 'verwijderingen' of 'opruimen' moet je altijd lief zijn. Simpelweg omdat het nogal wat problemen kan geven als een destructor exceptions gooit. Het maakt het ook makkelijker om gewoon altijd iets te verwijderen aan het einde, dan hoef je niet steeds van die checks in te bouwen overal.

bv. dit:

C++:

void foo() {
   Connection a, b;

   try {
      a.open();
      b.open();
   } catch (...) {
      a.close();
      b.close();
      throw;
   }
}

Maakt het wat makkelijker dan dat je eerst weer moet gaan kijken of a en b wel closed kunnen worden.

[bigbeng]

joepP schreef op 03 juni 2004 @ 11:25:
[...]



Dit fijne voorbeeld is -precies- wat Java in de hand werkt door af te dwingen dat je alles catched. Toegegeven, het is een schandalige manier van werken, maar waarom wordt je in godsnaam gedwongen om alles af te vangen?

Voorbeeldje. Je schrijft een applicatie die iets moet berekenen, bijvoorbeeld een of ander obscuur algoritme. Je wil dit over een bepaalde dataset draaien, en daarna eigenlijk nooit meer. De code gaat niet commercieel, wordt niet niet eens openbaar, je gebruikt het alleen zelf, waarschijnlijk eenmalig.

Waarom wordt ik dan gedwongen bij elke file-access een exception af te vangen? Ik draai dat ding alleen lokaal, de harddisk is nog lang niet vol, en schrijfrechten heb ik ook. Ik wil dan helemaal niets catchen, gewoon een keiharde fout als het misgaat. Maar ja, als je ergens diep in je code wat file-access doet -moet- je wel lokaal afvangen. Terwijl het default Java-gedrag bij (bijvoorbeeld) een null-pointer-exception precies is wat ik wil als het misgaat...

En ja, ik ben lui

Je kunt natuurlijk ook je Exception gewoon automatisch laten doorgooien door throws Exception aan je method mee te geven.
Mijn god, wat ken ik trouwens een boel brakke truuks zeg!

offtopic:
Mijn complimenten aan Alarmnummer trouwens met twee topics met meer dan 3 pagina's in het rood. Je snijdt blijkbaar de leuke topics aan

[joepP]

bigbeng schreef op 03 juni 2004 @ 11:30:
[...]

Je kunt natuurlijk ook je Exception gewoon automatisch laten doorgooien door throws Exception aan je method mee te geven.
Mijn god, wat ken ik trouwens een boel brakke truuks zeg!

Dan schrijf ik bijna nog liever een lege try-catch

[whoami]

bigbeng schreef op 03 juni 2004 @ 11:30:
[...]

Je kunt natuurlijk ook je Exception gewoon automatisch laten doorgooien door throws Exception aan je method mee te geven.
Mijn god, wat ken ik trouwens een boel brakke truuks zeg!

Mjah, zo'n brakke truuk is dat nu ook niet. (Toch niet zo brak als een lege catch).

offtopic:
Mijn complimenten aan Alarmnummer trouwens met twee topics met meer dan 3 pagina's in het rood. Je snijdt blijkbaar de leuke topics aan

offtopic:
Bij mij heeft dit topic nog altijd slechts 1 pagina hoor.

joepP schreef op 03 juni 2004 @ 11:32:
[...]

Dan schrijf ik bijna nog liever een lege try-catch

Ja, dat is handig zo'n struisvogeltechniek. Da's gewoon je kop in 't zand steken, en doen alsof er niets gebeurd is.

[ Voor 19% gewijzigd door whoami op 03-06-2004 11:35 ]

[Zoijar]

Een lege try catch hoeft niet perse altijd slecht te zijn. Stel dat je idd zo'n functie hebt die een handler uit de lijst verwijdert, en een exception gooit als die niet bestaat. Misschien wil je zeker weten dat de handler niet in de lijst zit, dan kan je een lege try catch eromheen gebruiken.

ie. je moet niet een bepaalde techniek niet gebruiken omdat er geschreven staat dat deze evil is. Maar je moet begrijpen waarom er geschreven staat dat de techniek meestal evil is, en dan voor jouw specifieke geval bepalen of dat daar ook voor opgaat. Zo niet, dan hoeft het voor jouw niet noodzakelijk evil te zijn.

[ Voor 36% gewijzigd door Zoijar op 03-06-2004 11:40 ]

[joepP]

whoami schreef op 03 juni 2004 @ 11:34:
[...]

Ja, dat is handig zo'n struisvogeltechniek. Da's gewoon je kop in 't zand steken, en doen alsof er niets gebeurd is.

Zeg leesmeester, waar staat dat ik lege try-catches schrijf? Of ben ik degene die niet kan lezen, en slaat je opmerking op het algemene geval en niet op mij?

[Janoz]

@Zoijar
hmm. En wat nu als er geen exception optreed of waneer de exception optreed bij a.open()? In het eerste geval worden ze niet afgesloten en in het tweede geval probeer je een niet geopende connectie te sluiten.

Ikzelf gebruik in dit geval vaak iets als:

Java:

Connection a = null;
Connection b = null;
try {
  a = new Connection();
  a.open();
  b = new Connection();
  b.open();
}
catch (SQLExeption e){
  throw e;
}
finally {
  Tools.saveClose(b);
  Tools.saveClose(a);
}

Waarbij de saveClose een methode is die controlleert of de connection niet null is en nog open is. Het opnieuw opgooien lijkt misschien wat raar, maar vaak probeer ik exceptions op een zo hoog mogenlijk niveau af te vangen. Persoonlijk vind ik het heel logisch dat een database object SQLExceptions op kan gooien. Eventueel wrap ik ze in eigen exceptions. Met struts kan ik vervolgens mbv global exceptions daar keurige pagina's omheen bouwen die aangeven dat er een probleem is met de database.

[ Voor 3% gewijzigd door Janoz op 03-06-2004 11:50 ]

[whoami]

joepP schreef op 03 juni 2004 @ 11:38:
[...]

Zeg leesmeester, waar staat dat ik lege try-catches schrijf? Of ben ik degene die niet kan lezen, en slaat je opmerking op het algemene geval en niet op mij?

Jij zegt dat je liever je excepties opeet ipv ze te re-throwen naar een hoger liggend niveau ?

[Janoz]

joepP schreef op 03 juni 2004 @ 11:32:
[...]

Dan schrijf ik bijna nog liever een lege try-catch

Gebruik gewoon een fatsoenlijke IDE. Zodra ergens een exception wordt verwacht krijg ik in mijn IntelliJ een uitroeptekentje die verschillende oplossingen bied:
1 Add to method signature
2 surround with try catch block (Wat weer een aanpasbaar template is)

Gebruik iig geen leeg catch blok. Die e.printStacktrace() is zo'n kleine moeite en gewoon een fatsoenlijke slordige oplossing.

Met 1 druk op de knop heb ik het dus al omzeild.

[Alarmnummer]

Ximinez schreef op 03 juni 2004 @ 08:05:
[...]
Precies, het voorbeeld laat nu juist geen uitzonderlijke situatie zien. Namelijk de voorwaarde is bekend. Dus de implementatie kan rekening houden met die voorwaarde. Niet als gevolg van het afwijken van die voorwaarde zelf een exception
genereren. Dat is wat ik bedoel met "Daar zijn Exception niet voor".

Heb jij mijn bericht goed gelezen?? Ik zeg: als door een of andere rare gekke fout van de programmeur die leeftijds fout nog niet is afgevangen (misschien valideerde de gui niet goed), en je wilt alsnog met die foute waarde iets gaan instellen, dan moet je een exception opwerpen. Je moet verhinderen dat je objecten in een inconsistente toestand kunnen raken en dat kan je perfect doen door op dit moment als laatste uitweg een exception op te werpen.

Het ging me verder ook niet om dat gui voorbeeld, maar het gaat mij om client programmeurs. Hoe lief ben je tegen je lot genooot. Slinger je hem een enorme lading (unchecked) exceptions voor de kiezen bij elke fout die hij maakt, of is er een bepaalde balans te vinden tussen: heej stumper je deed iets fout.. en ach.. he maakt niet uit. Ik ben dus op zoek naar dat balans

Verder: voor de mensen die zeggen dat exceptions traag zijn -> lees het woord: exception eens goed.Wat betekend dat? Uitzondering? Hoe vaak komen uitzonderingen voor? Nou waarschijnlijk niet zo vaak? Hoe erg is het dat dingen die niet zo vaak voorkomen wat langzamer zijn?

[ Voor 30% gewijzigd door Alarmnummer op 03-06-2004 11:51 ]

[joepP]

whoami schreef op 03 juni 2004 @ 11:41:
[...]

Jij zegt dat je liever je excepties opeet ipv ze te re-throwen naar een hoger liggend niveau ?

Als je even terugleest, zie je de misschien ook de context waarin ik die uitspraak doe. In het daar aangehaalde geval zal ik het liefste helemaal niets try-catchen. Maar ja, dat mag niet. Dus wordt ik gedwongen tot het lokaal System.out-en van een foutmelding, aangezien ik weinig zin heb om 5 niveaus diep throws Exception aan allerlei functies toe te voegen, en ook geen lege try-catches wil gebruiken.

Snappie?

[Zoijar]

Janoz schreef op 03 juni 2004 @ 11:40:
@Zoijar
hmm. En wat nu als er geen exception optreed of waneer de exception optreed bij a.open()? In het eerste geval worden ze niet afgesloten en in het tweede geval probeer je een niet geopende connectie te sluiten.

Daar ging het precies om, de close() methode is dus zo lief dat die geen exception gooit bij het sluiten van een gesloten connectie, en dus werkt deze code goed.
Bij geen exceptions heb je twee geopende connecties... wat je daar verder mee wil weet ik niet... je kan ze sluiten aan het eind van de functie. Maar dan zou ik als volgt doen...

Ga ervanuit dat elke funtie een exception kan gooien. Alloceer al je resources als smart-pointers op de stack. Zorg ervoor dat alle destructors altijd goed gaan, eventueel een warning log, maar NOOIT exceptions.
Dan hoef je niet alles af te vangen. Ik vang meestal zelfs alleen maar op highlevel af, en exit dan met de error uit de exception.what(). (of een error dialog...) Alles is dan ook meteen mooi opgeruimd vanwege de smartpointer die van de stack worden gehaald.

(nb. C++ kent geen 'finally' construct; vandaar)

[ Voor 3% gewijzigd door Zoijar op 03-06-2004 11:47 ]

[Janoz]

joepP schreef op 03 juni 2004 @ 11:25:
[...]



Dit fijne voorbeeld is -precies- wat Java in de hand werkt door af te dwingen dat je alles catched. Toegegeven, het is een schandalige manier van werken, maar waarom wordt je in godsnaam gedwongen om alles af te vangen?

Nou, het is maar net hoe je ertegenaan kijtk. Dit soort dingen kunnen altijd optreden alleen wordt je bij Java gedwongen er rekening mee te houden. Je kunt mij niet wijsmaken dat mensen die een lege catch toevoegen in het geval dit niet verplicht was niet te lui zijn om wel volledige errorhandling toe zouden voegen.

[joepP]

Janoz schreef op 03 juni 2004 @ 11:44:
[...]

Gebruik gewoon een fatsoenlijke IDE. Zodra ergens een exception wordt verwacht krijg ik in mijn IntelliJ een uitroeptekentje die verschillende oplossingen bied:
1 Add to method signature
2 surround with try catch block (Wat weer een aanpasbaar template is)

Gebruik iig geen leeg catch blok. Die e.printStacktrace() is zo'n kleine moeite en gewoon een fatsoenlijke slordige oplossing.

Met 1 druk op de knop heb ik het dus al omzeild.

Jullie hebben een te slecht beeld van mij...

Ik hoef (gelukkig!) bijna nooit met Java te werken. Als dat wel zo zal zijn had ik inderdaad een fatsoenlijke IDE gebruikt. Maar het (instal)leren van een nieuwe IDE voor een enkel rekenprogje kost me meer tijd dan het oplevert. Mijn kritiek is heel simpel. Ik zit nu continu dit soort code te kloppen:

code:

try {
  ...
}
catch (Exception exp) {
  e.printStacktrace();
}

Terwijl dat juist precies is wat Java standaard ook doet bij een Nullpointer-Exception. Waarom wordt ik gedwongen om die extra code typen?

[joepP]

Janoz schreef op 03 juni 2004 @ 11:47:
[...]

Nou, het is maar net hoe je ertegenaan kijtk. Dit soort dingen kunnen altijd optreden alleen wordt je bij Java gedwongen er rekening mee te houden. Je kunt mij niet wijsmaken dat mensen die een lege catch toevoegen in het geval dit niet verplicht was niet te lui zijn om wel volledige errorhandling toe zouden voegen.

Een lege try-catch is vele malen erger dan helemaal geen errorhandling. En in de praktijk schrijven matige programmeurs hele programma's vol met dit soort "handling".

[Alarmnummer]

joepP schreef op 03 juni 2004 @ 11:50:
[...]
Jullie hebben een te slecht beeld van mij...

Ik hoef (gelukkig!) bijna nooit met Java te werken. Als dat wel zo zal zijn had ik inderdaad een fatsoenlijke IDE gebruikt. Maar het (instal)leren van een nieuwe IDE voor een enkel rekenprogje kost me meer tijd dan het oplevert. Mijn kritiek is heel simpel. Ik zit nu continu dit soort code te kloppen:

Als jij zelf al toegeeft dat je de kantjes er een beetje van afloopt, waarom doe je dan serieus mee aan deze discussie? Ik wil hier de verhalen horen van mensen die professional willen worden of al zijn.

[joepP]

Alarmnummer schreef op 03 juni 2004 @ 11:52:
[...]

Als jij zelf al toegeeft dat je de kantjes er een beetje van afloopt, waarom doe je dan serieus mee aan deze discussie? Ik wil hier de verhalen horen van mensen die professional willen worden of al zijn.

Misschien moet je even wat replies terug lezen, waar ik in eerste instantie wel een normale "op niveau" reactie geef. Alleen ergerde ik me op dat moment toevallig nogal aan dat paternalistische Java, waardoor ik mezelf een enkel off-topic zinnetje permitteerde.

Sorry hoor.

[whoami]

Alarmnummer schreef op 03 juni 2004 @ 11:45:
[...]

Verder: voor de mensen die zeggen dat exceptions traag zijn -> lees het woord: exception eens goed.Wat betekend dat? Uitzondering? Hoe vaak komen uitzonderingen voor? Nou waarschijnlijk niet zo vaak? Hoe erg is het dat dingen die niet zo vaak voorkomen wat langzamer zijn?

Daarom zeg ik ook dat je excepties niet voor alles mag (mis)bruiken; zoals het voorbeeld van De Generaal.
Dergelijke controle hoort in de UI thuis, en om die controle te doen hoef je geen excepties te gebruiken. (Indien die naam in de UI niet ingevuld wordt, is het ook geen exceptie imo. Je kan verwachten dat de user dat vergeet).
Je kan dan wel in je BL object nog eens die controle doen, en indien de input daar niet geldig is, kan je een exception gooien. (Hier is het dan wel een exceptie omdat die naam verwacht ingevuld is, als het goed is, heb je dat op je UI laag opgevangen, waardoor een lege naam hier niet meer zou mogen voorvallen).

[ Voor 20% gewijzigd door whoami op 03-06-2004 12:01 ]

[Alarmnummer]

joepP schreef op 03 juni 2004 @ 11:54:
[...]

Misschien moet je even wat replies terug lezen, waar ik in eerste instantie wel een normale "op niveau" reactie geef. Alleen ergerde ik me op dat moment toevallig nogal aan dat paternalistische Java, waardoor ik mezelf een enkel off-topic zinnetje permitteerde.

Over het algemeen ben ik zelf bijna nooit checked exceptions nodig en wordt ik gelukkig ook niet vaak gedwongen om met trycatchblokken te werken of de exception te propageren. Het is denk ik ook een stukje ervaring om te weten wanneer je checked en wanneer je unchecked moet gebruiken.

ps: het ligt wel aan de technieken waar je mee bezig bent. Ga je met middleware aan de slag of met databases krijg je wel veel meer checked exceptions voor de kiezen.

[Janoz]

Omdat een runtime exception (wat een nullpointer exception is) anders wordt behandeld als een andere exception. Daarnaast kun je in je rekenprogje het try blok gewoon erg ruim zetten. Hierdoor hoef je het hele try catch stuk maar 1x in te tikken (en eventueel wat throws SomeException bij de method signatures)

[Janoz]

joepP schreef op 03 juni 2004 @ 11:51:
[...]

Een lege try-catch is vele malen erger dan helemaal geen errorhandling. En in de praktijk schrijven matige programmeurs hele programma's vol met dit soort "handling".

Je mist mijn punt. Dat ging namelijk vooral om de eerste zin. Je irriteerd je aan het feit dat java je dwingt rekening te houden met mogenlijk op kunnen tredende fouten en dat het hierdoor slordig programeren in de hand werkt. Die uitspraakt vind ik nogal tegenstrijdig.