[c#] waarom geen checked exceptions??

[Alarmnummer]

Ik ben de laatste tijd wat aan het experimenteren met c# omdat dit een aantal features heeft die ik ook graag bij java zou zien zoals properties en operator overloading. Maar ik ben tegen een enorm groot minpunt van c# aangelopen, en dat is het gebrek aan checked exceptions. Ze hebben gekeken naar talen waar er wel checked exceptions zijn zoals bij java, maar aangezien veel mensen dit niet goed wisten te gebruiken hebben ze er maar voor gekozen om geen checked exceptions toe te voegen voor c#.

Dit is natuurlijk ongelovelijk irritant, omdat je niet meer kan afdwingen dat mensen iets met 'oplosbare' exceptions gaan doen (afvangen/doorgeven). Maar ze hebben er wel gekozen dat zoiets als operator overloading er wel weer in komt (wat in mijn ogen tot meer problemen kan leiden dan checked exceptions). Ik vind dit echt een enorm gebrek aan c#.

Wat zijn jullie ideeen hierover?

[ Voor 3% gewijzigd door Alarmnummer op 27-01-2003 12:00 ]

[whoami]

Wat bedoel je precies met checked exceptions?

Bedoel je hiermee bv:

code:

public void DezeMethodGooitEenExceptie() throws MyException

oid? en dat, als je die method aanroept, je deze binnen een try block moet zetten en een catch blok voorzien voor MyException?

[Alarmnummer]

whoami schreef op 27 januari 2003 @ 12:01:
Wat bedoel je precies met checked exceptions?

Bedoel je hiermee bv:

code:

public void DezeMethodGooitEenExceptie() throws MyException

oid? en dat, als je die method aanroept, je deze binnen een try block moet zetten en een catch blok voorzien voor MyException?

Dat bedoel ik idd Een checked exception moet je of propageren of afvangen. En dit kan je compiletime dus al checken.

[whoami]

Hmmm... Aangezien ik geen ervaring daarmee heb (heb nog niet met een taal gewerkt die checked exceptions heeft zoals Java), mis ik dat dan ook niet in C#.
Ik zie er dan ook niet direct een voordeel van in. (Maar dat zal wel komen omdat ik er nog niet mee gewerkt heb).

[watzie]

>whoami : het lijkt met dat hij dat bedoelt ja.

Ik hou me nog niet bezig met c# maar werk wel al jaren intensief met java op het hoogste niveau en hoewel java soms rampzalig irritante quirks heeft is exception checking een van de onmisbare eigenschappen van een goede programmeertaal omdat je er door gedwongen wordt te kijken naar wat de code die je aanroept allemaal zou kunnen doen. Dat maakt het lastiger om snel quick en dirty code te maken maar dat is juist goed omdat je als je er eenmaal aan gewend bent veel beter je code 'gelijk goed' gaat invullen. Java dwingt dit af wat de beginner snel irriteert en afschrikt maar de ervaren programmeur erg gelukkig maakt. Nooit meer suffe bugs van het nivo 'shit daar had ik geen rekening mee gehouden'.
Ik HOOP dat je in c# op z'n minst wel excepties kan catchen en typechecken want dan is het nog te overzien voor een nauwgezette programmeur. Ik zou niet meer zonder kunnen iig. Als je inderdaad gelijk hebt dan is het een grote oversight. Ik kan me voorstellen dat ze bij MS daarvoor gekozen hebben om de 'visual prutsers' het niet te lastig te maken snel een progsel bij elkaar te klikken. Voor een amateur is het natuurlijk best lastig als hij ook nog eens moet snappen wat hij aan het doen is tov 'het moet gewoon doen wat ik wil (dwim code)'

[ Voor 3% gewijzigd door watzie op 27-01-2003 12:18 ]

[Alarmnummer]

Ik vind het idd ook een beetje vreemd. En als ze het toch te moeilijk vinden voor visual prutser, waarom hebben ze dit niet alleen in VB.NET toegepast ipv 'de' .NET taal: c#. En verder zitten er genoeg features in c# die je als zeer krachtig/gecompliceerd kan bestempelen, maar waarom dan in godsnaam geen checked exceptions????

[whoami]

[nohtml]

watzie schreef op 27 januari 2003 @ 12:17:


Ik HOOP dat je in c# op z'n minst wel excepties kan catchen en typechecken want dan is het nog te overzien voor een nauwgezette programmeur.

Dat kan je wel hoor.

[cablepokerface]

Alarmnummer ... kun je uitleggen waarom je dit zo'n krachtige feature vind ?

Ik ken checked exceptions ook uit Java maar heb ze nooit gebruikt ... een gebruiker van een Object moet namelijk zelf voor error afhandeling zorgen ...

Als je een procedure uitvoert van een classe waarvan je een instantie hebt gemaakt en de originele source code niet kent ... dan zou je wel code zijn als je die niet ter plaatse catched .... of iig geval een last-chance exception handler inbouwd.

[whoami]

[nohtml]

cablepokerface schreef op 27 januari 2003 @ 12:41:
Alarmnummer ... kun je uitleggen waarom je dit zo'n krachtige feature vind ?

Ik ken checked exceptions ook uit Java maar heb ze nooit gebruikt ... een gebruiker van een Object moet namelijk zelf voor error afhandeling zorgen ...

Voor zover ik het begrijp 'forceer' je de gebruiker dan dan hij de excepties die dat object kunnen gooien, moet opvangen/afhandelen.

[cablepokerface]

Voor zover ik het begrijp 'forceer' je de gebruiker dan dan hij de excepties die dat object kunnen gooien, moet opvangen/afhandelen.

Dat weet ik wel ... maar noem eens een concreet goed voorbeeld ...

[whoami]

Stel dat jij een class library schrijft, en dat die classes methods hebben die bepaalde excepties gooien, dan ga jij - als library programmeur- toch niet zorgen voor de afhandeling of de melding van die fouten?
Je weet nl. niet in welke 'situatie' die library door de applicatie-programmeur gebruikt wordt. Is het een Windows-client, is het in een web-applicatie.... De manier waarop je de gebruiker meldt dat er een fout is opgetreden zal in beide gevallen anders zijn.

[whoami]

* whoami heeft ff ge-googled.

The only geek religous war I've ever seen rage on internal lists since I got to M$ from as far back as when I was an intern haven't been the "Emacs vs. vi" or "GPL vs. BSDL" flame wars I am used to but instead checked vs. unchecked exceptions in C# licks. I've seen at least three of these on the main C# list with the first having occured when I was an intern.

Being a Java head, I'm strongly for checked exceptions while a lot of the C++ heads seemed to be for unchecked exceptions which I assume is why C# has unchecked exceptions since most of those folks are C++ hackers.

At least now my need for checked exceptions is satisfied with J# but that doesn't mean I don't bristle when I read blatant FUD against checked exceptions.

Checked en unchecked exceptions

Does Java need checked exceptions?


* whoami moet dit ook allemaal eens gaan lezen....

[cablepokerface]

Goeie tip ... vooral dit http://www.25hoursaday.com/CsharpVsJava.html#checked is een erg interessant artikel ...

[Soultaker]

Ik durf te stellen dat checked exceptions een vereiste te zijn om code te kunnen schrijven waarvan formeel vastgesteld kan worden dat die code geen exceptions gooit, zonder elke keer weer 'algemene' catch clauses te introduceren, waarover men het al jaren eens is, dat dat tot onduidelijke code en het moeizaam traceren van fouten leidt.

Het is inderdaad jammer dat C# wel andere stricte technieken kent, om de consistentie van de code te garanderen, maar geen checked exceptions. Ik kan die kritiek in het geval van Java echter omkeren: waarom werden er wel checked exceptions geintroduceerd, terwijl veel andere formele controles ontbreken?

Ik denk daarbij aan (onder andere) covariante array-typen en het ontbreken van generieke definities, die ervoor zorgen dat de programmeur moet vertrouwen op conventies en type casting. Allemaal (minstens) net zo 'onveilig' als de onzekerheid welke excepties op zouden kunnen treden in een methode.

En waarom zijn system exceptions eigenlijk niet checked? Omdat het dan 'te veel werk' wordt om er op te controleren? Is dat niet hetzelfde argument als nu bij C# gehanteerd wordt?

Ik kan me goed voorstellen dat checked exceptions niet zo zinnig zijn, als ze alleen maar voor bepaalde excepties gelden. Aan de andere kant is het heel vervelend exceptions te moeten afvangen of propageren, waarvan je weet dat ze niet voor kunnen komen (zoals division by zero exceptions, in de meeste algoritmen). Waarschijnlijk waren dit ook de redenen om in C++ geen checked exceptions te introduceren. Je kunt je ook afvragen of het ueberhaupt nuttig is om sommige system exceptions (zoals bijvoorbeeld OutOfMemory) te gooien, als er geen redelijke manier is om ze af te handelen.

Dit laatste pleit trouwens voor destructie van objecten, wat C++ wel en Java niet kent. Wanneer een destructor ervoor zorgt dat resources op juiste wijze opgeruimd worden (wat de bedoeling is, van een goede destructor) dan maakt het niet uit of er exceptions optreden, en of die afgehandeld worden. Mocht er een zeldzame OutOfMemory exception optreden, dan heeft de compiler ervoor gezorgd dat alle objecten op de juiste wijze opgeruimd worden. Het ontbreken van een fatsoenlijke destructiemethode in Java schept de noodzaak voor het afhandelen van excepties.

[ Voor 65% gewijzigd door Soultaker op 27-01-2003 13:17 ]

[Alarmnummer]

Daarom is het ook handig als je kan kiezen tussen checked en unchecked, zoals dat bij java ook kan. Ik zou er ook niet aan moeten denken om achtere iedere methode: throws NullPointerException, IllegalArguemntException etc etc te moeten plaatsen.

[Soultaker]

Alarmnummer schreef op 27 januari 2003 @ 13:17:
Daarom is het ook handig als je kan kiezen tussen checked en unchecked, zoals dat bij java ook kan. Ik zou er ook niet aan moeten denken om achtere iedere methode: throws NullPointerException, IllegalArguemntException etc etc te moeten plaatsen.

Hoe kun je kiezen dan? Voor zover ik weet ben je verplicht alle non-system exceptions af te handelen of te propageren.

[Alarmnummer]

Soultaker schreef op 27 January 2003 @ 13:18:
[...]

Hoe kun je kiezen dan? Voor zover ik weet ben je verplicht alle non-system exceptions af te handelen of te propageren.

Als je je exception van een Exception laat extenden heb je een checked exception. Laat je hem van RuntimeException extenden dan heb je een unchecked exception.

[edit]
ik zie trouwens net ook dat c# geen innerclasses heeft zoals java ze heeft. Dat worden dus weer veel onzinnige classes en gedonder met toegang tot members. Snik snik, welke debiel denkt nou dat dit geen nuttige feature is.

[ Voor 23% gewijzigd door Alarmnummer op 27-01-2003 13:35 ]

[watzie]

cablepokerface schreef op 27 januari 2003 @ 12:41:
Alarmnummer ... kun je uitleggen waarom je dit zo'n krachtige feature vind ?

Ik ken checked exceptions ook uit Java maar heb ze nooit gebruikt ... een gebruiker van een Object moet namelijk zelf voor error afhandeling zorgen ...

Als je een procedure uitvoert van een classe waarvan je een instantie hebt gemaakt en de originele source code niet kent ... dan zou je wel code zijn als je die niet ter plaatse catched .... of iig geval een last-chance exception handler inbouwd.

Het gaat erom dat de programmeur van een stuk code dat door een ander gebruikt gaat worden dmv het declareren van de excepties een contract afspreekt van 'de volgende fouten moet je zelf afhandelen' en wat je niet opgeeft daar mag de consumer dus vanuit gaan dat dat wel netjes afgehandeld wordt. Als je dat goed doet weet de consumer dus ook zonder dat ie de source kent wat hij mag verwachten van zo'n method.

[watzie]

Alarmnummer schreef op 27 januari 2003 @ 13:25:
[...]
Als je je exception van een Exception laat extenden heb je een checked exception. Laat je hem van RuntimeException extenden dan heb je een unchecked exception.

Daar moet je vervolgens wel heel secuur mee omspringen, omdat je een unchecked (en dat met name system exceptions) wel kunt catchen maar ze hebben wel (by design) side-effects die je niet kunt voorkomen. Runtimeexceptions extenden en zelf gaan throwen is een gevaarlijk spelletje, eigenlijk mag je dat alleen doen in een fubar situatie (alles ist vorbei maar je krijgt een laatste kans om nog een nette melding aan de gebruiker te geven). Een runtime exception (bijv EJBException) in een statefull sessionbean betekent dus wel mooi dat je je state kwijt bent, of je hem nou catcht of niet.

[watzie]

Alarmnummer schreef op 27 January 2003 @ 13:17:
Daarom is het ook handig als je kan kiezen tussen checked en unchecked, zoals dat bij java ook kan. Ik zou er ook niet aan moeten denken om achtere iedere methode: throws NullPointerException, IllegalArguemntException etc etc te moeten plaatsen.

Precies, het zou onzinnig zijn om als auteur van een brokje code alle mogelijk stomheden die de aanroeper erin kan gooien te voorzien. Dat soort fouten is de verantwoordelijheid van de gebruiker. De dingen die hij niet kan weten dat hij fout zou kunnen doen (en je eigen interne nullpointers etc.) moet je natuurlijk wel zelf netjes en onzichtbaar voorkomen.
Maar omdat je nooit alle mogelijke manieren van gebruik kan voorspellen kun je dus wel vast duidelijkmaken wat je code wel en niet trekt en hoe daarop gereageerd wordt. De gebruiker mag dan de foutafhandeling van de gedeclareerde exceptions doen om de oorspronkelijke bouwer niet (of niet altijd) kan weten wat de programmeurgebruiker in dat geval het liefst zou willen doen (melding aan de gebruiker, crashen, afsluiten, opnieuw proberen etc.)

[whoami]

watzie: gebruik ff de edit - knop ipv meerdere posts achter elkaar te doen.
(Of nog beter: lees eerst het volledige topic door, en reageer dan).

[Alarmnummer]

watzie schreef op 27 January 2003 @ 13:33:
[...]

Daar moet je vervolgens wel heel secuur mee omspringen, omdat je een unchecked (en dat met name system exceptions) wel kunt catchen maar ze hebben wel (by design) side-effects die je niet kunt voorkomen. Runtimeexceptions extenden en zelf gaan throwen is een gevaarlijk spelletje, eigenlijk mag je dat alleen doen in een fubar situatie (alles ist vorbei maar je krijgt een laatste kans om nog een nette melding aan de gebruiker te geven).

Ik gebruik het oa voor precondities en exception waar ik eigelijk niet van verwacht dat ze opgelost gaan worden. Hierdoor kan je er idd uitknallen, maar je blijft niet tenonrechte draaien, of de gebruiker opzadelen met een enorme lading exceptions die hij niet kan verhelpen.

Een runtime exception (bijv EJBException) in een statefull sessionbean betekent dus wel mooi dat je je state kwijt bent, of je hem nou catcht of niet.

Ik heb het tot zover altijd kunnen redden zonder EJB Ik hou meer van POJO`s

[watzie]

whoami schreef op 27 januari 2003 @ 13:37:
watzie: gebruik ff de edit - knop ipv meerdere posts achter elkaar te doen.
(Of nog beter: lees eerst het volledige topic door, en reageer dan).

Yessir

Pleeg altijd te vinden dat het handig is threaded te reageren omdat je ziet waar iets bij hoort, macht der gewoonte. Hier heb je wel een beetje gelijk. Ben ondertussen hard aan het werk dus zodra ik 'leven' zie dan flats ik er meteen een commentaartje bij. 'k Zal het niemeer doen

[Soultaker]

watzie schreef op 27 januari 2003 @ 13:36:
Precies, het zou onzinnig zijn om als auteur van een brokje code alle mogelijk stomheden die de aanroeper erin kan gooien te voorzien. Dat soort fouten is de verantwoordelijheid van de gebruiker. De dingen die hij niet kan weten dat hij fout zou kunnen doen (en je eigen interne nullpointers etc.) moet je natuurlijk wel zelf netjes en onzichtbaar voorkomen.
Maar omdat je nooit alle mogelijke manieren van gebruik kan voorspellen kun je dus wel vast duidelijkmaken wat je code wel en niet trekt en hoe daarop gereageerd wordt. De gebruiker mag dan de foutafhandeling van de gedeclareerde exceptions doen om de oorspronkelijke bouwer niet (of niet altijd) kan weten wat de programmeurgebruiker in dat geval het liefst zou willen doen (melding aan de gebruiker, crashen, afsluiten, opnieuw proberen etc.)

Volgens jou redenatie mag een methode dus wel null pointer of bad parameter exceptions gooien als de caller ongeldige argumenten meegeeft. De caller moet deze exceptions vervolgens catchen (omdat, zoals je zelf al zegt, het niet netjes is om de code op een nivo hoger ermee op te zadelen). Wat nu als ik wel weet wat voor argumenten ik doorgeef, omdat ik ze ter plekke construeer of al eerder gecontroleerd heb op geldig/niet-null-zijn? In plaats van function calls van een enkele regel, krijg ik 'n uitgebreide try-catch-clausule voor een situatie waarvan ik weet dat hij niet op kan treden. En als hij toch optreedt, (omdat de methode die ik aanroep van een andere versie is dan ik verwacht) dan zou ik niet weten wat ik er aan moest doen; ik heb het immers goed gedaan. Ik moet dan maar een leeg catch blok maken om de exceptie te onderdrukken.

Wanneer dan toch, door incompatibiliteit tussen de klassen, een exception optreed, dan wordt die gesust, maar doet de applicatie niet wat er verwacht werd. Waar het fout ging is verder een raadsel; afhankelijk van de complexiteit van de applicatie worden er per operaties honderden of duizenden methoden aangeroepen en in elk daarvan zou iets mis kunnen gaan. Had ik dan niet beter die excepties kunnen negeren, zodat ze in zo'n uitzonderlijk geval gepropageerd worden tot op het diepste nivo, waarna de JRE ze overzichtlijk op het scherm weergeeft, met oorsprong en stack trace, zodat de ontwikkelaar/gebruiker zich er in ieder geval bewust van is dat er iets fout gaat, en waar dat precies gebeurd?

Ik ben geen onverdeeld voorstander van de ene (Java) of andere (C++) manier van exception handling, maar ik kan me voorstellen dat er ook voor het afhandelen van unchecked exceptions wat te zeggen valt. Het simpele feit dat je in Java op kunt geven welke exceptions een methode gooit, is al genoeg indicatie voor de programmeur die de methode gebruikt, waarop gecatched moet worden, indien nodig. Je zou kunnen zeggen dat dit soort informatie ook in commentaar of documentatie aangeboden zou kunnen worden, en dat het verplicht afhandelen van exceptions de code nodeloos ingewikkeld maakt en de kans dat fouten gedetecteerd worden kleiner maakt.

offtopic:
Ik vind het wel overzichtelijk dat watzie, of anderen, per bericht een enkele reactie geven, eigenlijk.

[ Voor 4% gewijzigd door Soultaker op 27-01-2003 13:49 ]

[watzie]

Alarmnummer schreef op 27 januari 2003 @ 13:38:
[...]

Ik gebruik het oa voor precondities en exception waar ik eigelijk niet van verwacht dat ze opgelost gaan worden. Hierdoor kan je er idd uitknallen, maar je blijft niet tenonrechte draaien, of de gebruiker opzadelen met een enorme lading exceptions die hij niet kan verhelpen.

Da's natuurlijk ook correct gebruik, zolang je het maar niet doet omdat je het te lastig vindt om een fout te declareren en weer te catchen. In de praktijk van grote projecten met meerdere programmeurs een meerdere strikt gescheiden tiers krijg je dan ineens low level exceptions die helemaal tot de gebruiker doorbubbelen en als er iets vernederend is is het wel een gebruiker die een stacktrace voor z'n neus krijgt

Ik heb het tot zover altijd kunnen redden zonder EJB Ik hou meer van POJO`s

Achja, vroeger, toen de wereld nog klein was en je fat clients kon bouwen... *zucht nostalgisch denkend aan de hobby tijd *

[Alarmnummer]

watzie schreef op 27 January 2003 @ 13:48:
[...]

Da's natuurlijk ook correct gebruik, zolang je het maar niet doet omdat je het te lastig vindt om een fout te declareren en weer te catchen. In de praktijk van grote projecten met meerdere programmeurs een meerdere strikt gescheiden tiers krijg je dan ineens low level exceptions die helemaal tot de gebruiker doorbubbelen en als er iets vernederend is is het wel een gebruiker die een stacktrace voor z'n neus krijgt

*zucht* een stacktrace. Ik moet nog een paar week debuggen aan een oude c/delphi applicatie en hierbij is zo nu en dan de hele applicatie ineens verdwenen zonder ook maar een melding.

Achja, vroeger, toen de wereld nog klein was en je fat clients kon bouwen... *zucht nostalgisch denkend aan de hobby tijd *

EJB is niet altijd verplicht hoor Het voordeel aan POJO`s is dat je zelf 100% controle hebt over de opbouw van je domein objecten en dat je niet vast zit aan een percistance techniek zoals bv ejb. Je kan gerust op de achtergrond EJB`s gebruiken bij domein objecten, maar ik wil ze niet iedere keer voor mijn neus krijgen en ik wil ook niet in mijn ontwerp daardoor gehinderd worden.

[edit]
Ik ga weer helemaal offtopic. het lijkt me reuze interessant om verder te discussieren over EJB en POJO, maar dan kunnen we dat beter even doen in een ander topic.

[ Voor 12% gewijzigd door Alarmnummer op 27-01-2003 14:03 ]

[watzie]

Soultaker schreef op 27 januari 2003 @ 13:47:
[...]
Volgens jou redenatie mag een methode dus wel null pointer of bad parameter exceptions gooien als de caller ongeldige argumenten meegeeft.

Inderdaad. Ik zelf zet dat er overigens wel meestal in de javadoc bij. Wbt ongeldige argumenten dan definieer ik daar, mits zinnig, custom exceptions bij.

De caller moet deze exceptions vervolgens catchen (omdat, zoals je zelf al zegt, het niet netjes is om de code op een nivo hoger ermee op te zadelen). Wat nu als ik wel weet wat voor argumenten ik doorgeef, omdat ik ze ter plekke construeer of al eerder gecontroleerd heb op geldig/niet-null-zijn? In plaats van function calls van een enkele regel, krijg ik 'n uitgebreide try-catch-clausule voor een situatie waarvan ik weet dat hij niet op kan treden.

Nu geef je dus een mooi voorbeeld: ben jij als aanroeper verantwoordelijk voor het doorgeven van gegarandeerd geldige arguments? Het is wel slim natuurlijk maar de maker van de blackbox kan ook alvast beloven te proberen zoveel mogelijk te checken. Dat kan in voorkomende gevallen dus een hoop dubbele code voorkomen. Het ligt er maar aan wat je wilt maken. De kracht ligt erin dat je precies KUNT definieren wat je wel en niet doet. Het HOEFT niet, dan laat je gewoon alles foutgaan en mag de aanroeper het oplossen.

En als hij toch optreedt, (omdat de methode die ik aanroep van een andere versie is dan ik verwacht) dan zou ik niet weten wat ik er aan moest doen; ik heb het immers goed gedaan. Ik moet dan maar een leeg catch blok maken om de exceptie te onderdrukken.

Dat kun je idd doen. Typisch geval van een 'this cannot happen' error. In zo'n geval moet je dus wel zorgen dat je op z'n minst een system.out.println met stacktrace of andere logfunctie aanroept zodat je bij het testen ziet van hee dit mag/kan niet maar het gebeurt toch.

Wanneer dan toch, door incompatibiliteit tussen de klassen, een exception optreedt, dan wordt die gesust, maar doet de applicatie niet wat er verwacht werd. Waar het fout ging is verder een raadsel; afhankelijk van de complexiteit van de applicatie worden er per operaties honderden of duizenden methoden aangeroepen en in elk daarvan zou iets mis kunnen gaan. Had ik dan niet beter die excepties kunnen negeren, zodat ze in zo'n uitzonderlijk geval gepropageerd worden tot op het diepste nivo, waarna de JRE ze overzichtlijk op het scherm weergeeft, met oorsprong en stack trace, zodat de ontwikkelaar/gebruiker zich er in ieder geval bewust van is dat er iets fout gaat, en waar dat precies gebeurd?

In plaats van 'negeren' declareer je ze dan toch zelf als throws? Je wilt serieuze foutafhandeling van dat soort gekke situaties toch ook concentreren in een klein stuk van je systeem. Dan hoef je dus maar op een paar plekken de echte catch te doen.
Je kunt zelf natuurlijk gewoon door laten propageren, je rethrowt tenslotte als je netjes werkt zo'n 'dit kan niet gebeuren' fout waarbij je hem evt omvormt naar een andere exceptie met de oorspronkelijke fout in de constructor. Daardoor heb je nog steeds altijd overal de volledige stacktrace tot je beschikking.

Ik ben geen onverdeeld voorstander van de ene (Java) of andere (C++) manier van exception handling, maar ik kan me voorstellen dat er ook voor het afhandelen van unchecked exceptions wat te zeggen valt. Het simpele feit dat je in Java op kunt geven welke exceptions een methode gooit, is al genoeg indicatie voor de programmeur die de methode gebruikt, waarop gecatched moet worden, indien nodig. Je zou kunnen zeggen dat dit soort informatie ook in commentaar of documentatie aangeboden zou kunnen worden, en dat het verplicht afhandelen van exceptions de code nodeloos ingewikkeld maakt en de kans dat fouten gedetecteerd worden kleiner maakt.

Qua documentatie klopt dit volledig, als je netjes javadoct (en in de meeste ontwikkelomgevingen voor java heb je zelfs al primitieve documentatie door inspection/reflection zonder dat je er iets voor hoeft te doen) dat kun je het al heel helder maken voor de consumer. Maarja je moet dan ook wel echt doccen en dat wordt niet afgedwongen. Exceptions declaren doet dat dus wel.
Verder heb je helemaal gelijk: als jij je helemaal uitleeft in het declareren van de meest uitgebreide throws dan bereik je hoogstens dat de gebruik van je componentje al gauw zegt 'ja daahaag' en catch(Exception e){} gaat doen. Dan doe je het dus ook niet goed en geloof me ik ken het gevoel (zeker als je met ejb's gaat spelen wordt je helemaal wild van de 'onzinnige' catches die je de hele tijd loopt te schrijven).

[EfBe]

Alarmnummer schreef op 27 January 2003 @ 11:59:
Ik ben de laatste tijd wat aan het experimenteren met c# omdat dit een aantal features heeft die ik ook graag bij java zou zien zoals properties en operator overloading. Maar ik ben tegen een enorm groot minpunt van c# aangelopen, en dat is het gebrek aan checked exceptions. Ze hebben gekeken naar talen waar er wel checked exceptions zijn zoals bij java, maar aangezien veel mensen dit niet goed wisten te gebruiken hebben ze er maar voor gekozen om geen checked exceptions toe te voegen voor c#.

Checked Exceptions zijn juist uit C# gelaten om een aantal goed gefundeerde redenen. Zoek eens op "Eric Gunnerson Checked Exceptions" in de google groups en filter op Eric Gunnerson als author (anders krijg je nog meer postings). Eric Gunnerson is een van de C# designers en legt meerdere keren uit waarom Checked Exceptions niet nuttig zijn en averechts kunnen werken.

Dezelfde discussie als die jij nu aanzwengelt is nog steeds gaande (in 3 of 4 threads nu geloof ik) in de C# newsgroup en de java.advocacy newsgroup tegelijk en ik denk dat er gezamelijk al zo'n 1000 postings aan gewijd zijn. Iemand vroeg vanochtend wat nu de stand van de discussie was want hij zag door alle moddergooiwedstrijden de bomen niet meer. Ik heb toen maar geantwoord dat de anti's vinden dat CE suckt en dat de pro-CE mensen vinden dat het geweldig is.

Dit is natuurlijk ongelovelijk irritant, omdat je niet meer kan afdwingen dat mensen iets met 'oplosbare' exceptions gaan doen (afvangen/doorgeven). Maar ze hebben er wel gekozen dat zoiets als operator overloading er wel weer in komt (wat in mijn ogen tot meer problemen kan leiden dan checked exceptions). Ik vind dit echt een enorm gebrek aan c#.

Er zijn echt waslijsten met argumenten te verzinnen waarom Checked Exceptions een ramp zijn. Ik durf het wel te stellen dat als checked exceptions worden toegevoegd aan C# ik OF alleen maar unchecked exceptions (runtime exceptions) ga gebruiken of een totaal andere taal. Maar goed, lees de voltallige serie threads in de C# newsgroup (die jij inmiddels wel gevonden hebt zag ik ) over dit onderwerp maar door en leer van de voor/tegens van CE mbt .NET. Vooral multi-language, late binding dmv reflection, interface breaking in grote projecten vs. dure, lange refactoring en Exception is an errorreporting tool vs Exceptions are exceptional, use returncodes when appropriate.

Vooral dat laatste is niet meer mogelijk met CE zonder bakken met werk, waarbij je dus een centrale exception handler hebt voor de exceptions en je verder op lokaal niveau exceptions handlet indien nuttig en verder werkt met return values.

Mijn indruk na 4 weken holy war-flames over dit onderwerp is dat de mensen die ertegen zijn pragmatisch omgaan met de nadelen van CE en de mensen die voor zijn puur omdat java het ook heeft het willen invoeren en blind zijn voor de nadelen van CE. Ik heb ook nog geen pro-CE persoon gezien die niet de troll uithing of iig niet een java-advocate was. Wel heb ik goede postings gezien van ene Bruno die jarenlang Java met CE had gebruikt en er zo zat van was en blij was dat CE niet in C# zat, hij legde uit goed uit, met goede voorbeelden en ook waarom het debat niet tot een einde kwam.

Wanneer je de complete threads gaat lezen, sla de postings van 'petilon' over, dat is een Oracle werknemer die betaald wordt om te trollen in Microsoft newsgroups.

[Soultaker]

watzie schreef op 27 januari 2003 @ 14:10:
Nu geef je dus een mooi voorbeeld: ben jij als aanroeper verantwoordelijk voor het doorgeven van gegarandeerd geldige arguments? Het is wel slim natuurlijk maar de maker van de blackbox kan ook alvast beloven te proberen zoveel mogelijk te checken. Dat kan in voorkomende gevallen dus een hoop dubbele code voorkomen.

Juist niet! Als in een hele serie van aanroepen dezelfde reference elke keer wordt gecontroleerd op null-zijn, wordt er een hele reeks aan zinloze handelingen achter elkaar uitgevoerd, zowel tijdens de executie als bij het schrijven van de code. Het is vaak gewoon veel te kostbaar om alle mogelijke ongeldige waarden af te vangen. Er valt dus wat voor te zeggen, om, zoals in Python gebruikelijk is, van de gebruiker te eisen dat hij een methode goed gebruikt. Het is natuurlijk praktisch om fouten tijdelijk af te vangen, maar ze kunnen dan beter direct naar voren komen door middel van een core dump, dan dat ze door ingewikkelde exception handling code verdoezelt worden.

Het ligt er maar aan wat je wilt maken. De kracht ligt erin dat je precies KUNT definieren wat je wel en niet doet. Het HOEFT niet, dan laat je gewoon alles foutgaan en mag de aanroeper het oplossen.

In Java moet je het dus wel specificeren. Ik vind dat een methode uitsluitend 'redelijke' excepties moet specificeren. Als een methode een hele waslijst van excepties declareert, hoe weet ik als gebruiker dan welke daarvan zo onwaarschijnlijk/onpraktisch zijn dat de methode ze zelf niet kan afhandelen, en welke er door de methode zelf gegenereerd of 'bewust' doorgegeven worden? Die eerste wil ik namelijk niet afhandelen, de tweede zeker wel. Naar mijn idee is het ook niet zinnig om de eerste te declareren.

Dat kun je idd doen. Typisch geval van een 'this cannot happen' error. In zo'n geval moet je dus wel zorgen dat je op z'n minst een system.out.println met stacktrace of andere logfunctie aanroept zodat je bij het testen ziet van hee dit mag/kan niet maar het gebeurt toch.

Ach ja, dat had ik inderdaad niet gezegd. Blijft het feit dat het verplicht schrijven van een "catch(Exception x) { x.printStackTrace();}" clause onnodig moeilijk is en de code onoverzichtelijk maakt, zonder voordelen te bieden: zonder checked exceptions zou die exception namelijk doorvallen tot de runtime environment 'm weergeeft.

In plaats van 'negeren' declareer je ze dan toch zelf als throws? Je wilt serieuze foutafhandeling van dat soort gekke situaties toch ook concentreren in een klein stuk van je systeem. Dan hoef je dus maar op een paar plekken de echte catch te doen.

Dan zit je wel weer met het waslijst-syndroom, dat effectief werken met exceptions voor de caller moeilijk maakt (nogmaals: welke zijn waarschijnlijk?). Dan kies ik nog liever voor de oplossing waarin ik overvloedig catch-clauses introduceer. Dat gaat dan ten koste van de leesbaarheid van de code.

Dan doe je het dus ook niet goed en geloof me ik ken het gevoel (zeker als je met ejb's gaat spelen wordt je helemaal wild van de 'onzinnige' catches die je de hele tijd loopt te schrijven).

De vraag is of je 'goed doen' formeel moet forceren (zoals Java op dit vlak wel probeert) of dat je het aan de programmeur overlaat (zoals Python en C++ met excepties omgaan). Waarschijnlijk wil je een beetje van beide, maar waar ligt de grens? Ik vind het nog steeds gek dat Java op dit punt zo formeel is, en op andere punten grote steken laat vallen. Kies dan voor het ene standpunt, of het andere, maar deze mengeling van slordig en strict maakt de taal er niet makkelijker op.

[ Voor 7% gewijzigd door Soultaker op 27-01-2003 14:50 ]

[MSalters]

Om er het C++ standpunt weer bij te halen: Checked Exceptions zitten niet in C++ omdat ze niet kunnen worden geintegreerd met generics (templates). Dat is waarschijnlijk geen fundamentele onmogelijkheid, maar een geval van uit de hand lopende complexiteit. Andere talen zouden het dus misschien wel kunnen. Het is voor die talen iets wat zeker overwogen moet worden tijdens het toevoegen vn generics.

Een groot aantal C++ experts ziet inmiddels exception specifications als een minder goed idee, dus wat C++ betreft zijn CE uitgesloten. Dat zal ook wel meespelen bij C#

[Soultaker]

MSalters schreef op 27 January 2003 @ 19:05:
Om er het C++ standpunt weer bij te halen: Checked Exceptions zitten niet in C++ omdat ze niet kunnen worden geintegreerd met generics (templates).

Wat is daar moeilijk aan dan?

[EfBe]

MSalters schreef op 27 januari 2003 @ 19:05:
Om er het C++ standpunt weer bij te halen: Checked Exceptions zitten niet in C++ omdat ze niet kunnen worden geintegreerd met generics (templates). Dat is waarschijnlijk geen fundamentele onmogelijkheid, maar een geval van uit de hand lopende complexiteit. Andere talen zouden het dus misschien wel kunnen. Het is voor die talen iets wat zeker overwogen moet worden tijdens het toevoegen vn generics.

Is het niet zo dat C++ wel een 'throw' clause ala java's 'throws' heeft om exceptions in checked form te kunnen specificeren maar dat geen compiler deze exceptions ook echt checkt?

Je generics punt is wel interessant, want het is nl. in die complete 1000+ posting thread waar echt geen domme mensen aan meedoen, niet 1 keer geopperd, dus verfrissend Weet iemand hoe Java v1.5 (de generics java) omgaat met checked exceptions?

Een groot aantal C++ experts ziet inmiddels exception specifications als een minder goed idee, dus wat C++ betreft zijn CE uitgesloten. Dat zal ook wel meespelen bij C#

Wat C++ developers aanspreekt is topprioriteit voor C#, dat onderstreepte Eric Gunnerson vandaag nog. Maar de redenen die hij aangaf voor het niet integreren van CE in C# bevatte vziw geen "C++ heeft ze wel maar gebruikt ze niet, dus heeft C# geen CE"-like reden.

Overigens ben ik wel benieuwd waarom 'exceptions' als geheel als een minder goed idee worden gezien, want ze kunnen nl. wel een positieve inbreng hebben in code, nl. een generieke manier om een stuk code te verlaten omdat een onverwachte toestand is opgetreden.

[Alarmnummer]

EfBe schreef op 27 januari 2003 @ 20:31:
[...]

Is het niet zo dat C++ wel een 'throw' clause ala java's 'throws' heeft om exceptions in checked form te kunnen specificeren maar dat geen compiler deze exceptions ook echt checkt?

Je generics punt is wel interessant, want het is nl. in die complete 1000+ posting thread waar echt geen domme mensen aan meedoen, niet 1 keer geopperd, dus verfrissend Weet iemand hoe Java v1.5 (de generics java) omgaat met checked exceptions?

Zoals het hoort

code:

class A<B>{
    B foo(B b)throws AException<B>;
}

of voor de liefhebbers

code:

class A<E extends Exception>{
      void foo()throws E;
}

Kan je erin parametriseren of je een checked of unchecked exception wil

zie http://forum.javahova.net/topic.php?id=840

[ Voor 8% gewijzigd door Alarmnummer op 27-01-2003 20:40 ]

[Glimi]

EfBe schreef op 27 January 2003 @ 20:31:
Je generics punt is wel interessant, want het is nl. in die complete 1000+ posting thread waar echt geen domme mensen aan meedoen, niet 1 keer geopperd, dus verfrissend Weet iemand hoe Java v1.5 (de generics java) omgaat met checked exceptions?

[vanHorenZeggen]
Generics in java zitten niet doorgevoerd op ByteCode niveau. Het is gewoon een kwestie van substitutie van een Preprocessor, waarna de compiler er pas overheen gaat. Voor de compiler is het dan ook gewoon gelijk aan > 1.5 Java [/vanHorenZeggen]

[Soultaker]

Glimi schreef op 27 januari 2003 @ 20:40:
Het is gewoon een kwestie van substitutie van een Preprocessor, waarna de compiler er pas overheen gaat.

In principe is dat precies hetzelfde wat een C++ compiler doet. Ik zie dan ook niet waarom checked exceptions een probleem zouden zijn in combinatie met templates; of 't nu om C++ of Java gaat.

[Verwijderd]

Soultaker schreef op 27 January 2003 @ 13:47:
[...]
Het simpele feit dat je in Java op kunt geven welke exceptions een methode gooit, is al genoeg indicatie voor de programmeur die de methode gebruikt, waarop gecatched moet worden, indien nodig. Je zou kunnen zeggen dat dit soort informatie ook in commentaar of documentatie aangeboden zou kunnen worden, en dat het verplicht afhandelen van exceptions de code nodeloos ingewikkeld maakt en de kans dat fouten gedetecteerd worden kleiner maakt.

Ben ik niet helemaal mee eens... er zijn situaties waarin excepties echt verwacht kunnen worden en dus ook echt zouden *moeten* worden afgevangen ... denk bv aan alles wat met io heeft te maken.. stel dat je van een socket leest.... je hebt geen controle over de server die de data naar je toestuurt... je kan daar als programmeur niet omheen, die socket kan kapot gaan... daar moet je dus wel rekening mee houden...

Edit : oeps sorry reageerde wel op iets heel ouds... had niet door dat ik op page 1 van 2 zat... sorry

[ Voor 6% gewijzigd door Verwijderd op 27-01-2003 21:06 ]

[EfBe]

Verwijderd schreef op 27 January 2003 @ 21:03:
[...]

Ben ik niet helemaal mee eens... er zijn situaties waarin excepties echt verwacht kunnen worden en dus ook echt zouden *moeten* worden afgevangen ... denk bv aan alles wat met io heeft te maken.. stel dat je van een socket leest.... je hebt geen controle over de server die de data naar je toestuurt... je kan daar als programmeur niet omheen, die socket kan kapot gaan... daar moet je dus wel rekening mee houden...

Dit is een van de breekpunten in de discussie: exception as exceptional state vs. exception as errorreporting tool.

Ik gebruik bv NOOIT exceptions om een zekere verwachte state terug te sturen naar de caller, ALTIJD returnvalues. Alleen wanneer een onverwachte toestand ontstaat (bv je hebt net File.Exists(fileName) gedaan en die gaf aan de file is er, daarna ga je dus lezen en het platform geeft een IOFileNotFound exception, dan propagate die fijn naar boven).

Anderen gebruiken exceptions waar een afwijkende toestand geconstateerd wordt. Mooi voorbeeld is bv een test voordat een actie gedaan wordt, of de huidige user wel de rechten heeft om die actie te doen. Normaliter roep je bv aan:

if(HasRights(Rights.WriteFile))
{
//write the file
}

maar in het geval van Exceptions gebruiken voor errorreporting moet je doen (als je consequent bent!)

try
{
// write file
}
catch (AccessVoilationException ex)
{
// handle this exception here
}
// etc...

Hang je het laatste aan, dan zijn checked exceptions in zekere zin nuttig, hang je het eerste aan, dan zijn CE een nachtmerrie, ivm de vele throw clauses die je moet definieren en stompzinnige retrow catch clauses.

Ik zei met opzet 'als je consequent bent', want je mag geen consessies doen, vind ik, aan een paradigma als je dat verkondigd als "zo moet het", in sommige situaties.

Aan checked exceptions kleven ook de definitie van exception trees in interfaces. Vooral dit aspect vind ik erg kortzichtig, want een exception die aan een method signature hangt, is daar geplaatst ivm de implementatie (de body) van de method. Wijzigt die methodbody (maar dus niet de functionaliteit noch de header) dan wijzigt dus ook de signature, en daarmee de interface. Dit resulteert in exception swallowing/encapsulation, wat het hele idee van checked exceptions omzeep helpt.

Maar nogmaals, lees die thread in de C# newsgroup maar door, want alles (behalve de generics relatie) is al gezegd.

Over de generics relatie: Alarmnummer: je zegt nu wel dat je mbv de template de exception ook afhankelijk kunt maken van je inputtypes van je template, maar dat impliceert ook dat je je exception hierarchie templatificeert. Wat inhoudt dat je catch clauses dus complexer worden, want je moet voor ieder type een aparte clause opnemen. (of ook templatificeren). Lijkt me een highroad naar onleesbare code met een veel te hoge complexiteitsfactor (lees: schiet zn doel ver en ver voorbij, nl. KISS)

[Alarmnummer]

EfBe schreef op 27 January 2003 @ 21:36:
Dit is eeOver de generics relatie: Alarmnummer: je zegt nu wel dat je mbv de template de exception ook afhankelijk kunt maken van je inputtypes van je template, maar dat impliceert ook dat je je exception hierarchie templatificeert. Wat inhoudt dat je catch clauses dus complexer worden, want je moet voor ieder type een aparte clause opnemen. (of ook templatificeren). Lijkt me een highroad naar onleesbare code met een veel te hoge complexiteitsfactor (lees: schiet zn doel ver en ver voorbij, nl. KISS)

je hebt geen fantasie

Maar idd, dit is ook niet iets dat ik erg fijn zou vinden als ik het tegen zou komen.

[ Voor 8% gewijzigd door Alarmnummer op 27-01-2003 21:42 ]

[mbravenboer]

EfBe: Je generics punt is wel interessant, want het is nl. in die complete 1000+ posting thread waar echt geen domme mensen aan meedoen, niet 1 keer geopperd, dus verfrissend Weet iemand hoe Java v1.5 (de generics java) omgaat met checked exceptions?

Eigenlijk gewoon zoals je zou verwachten bij geparameterizeerde typen. Ik zie de problemen bij C++ templates niet direct, maar in ieder geval zijn er bij het design an Generic Java voor zover ik weet niet echt problemen geweest met exceptions. Geparameterizeerde typen zijn in Java ook echte geparameterizeerde typen en geen templates. Waarschijnlijk zit daar het verschil in. Generic Java wordt gecompileerd met behulp van type erasure, wat dus een hele andere methode is.

Glimi: [vanHorenZeggen]Generics in java zitten niet doorgevoerd op ByteCode niveau. Het is gewoon een kwestie van substitutie van een Preprocessor, waarna de compiler er pas overheen gaat. Voor de compiler is het dan ook gewoon gelijk aan > 1.5 Java [/vanHorenZeggen]

Dat is echt wel een hele ranzige omschrijving . Generic Java wordt niet fraai gecompileerd, maar zo vies is het nu ook weer niet . De compiler heeft wel degelijk kennis van geparameterizeerde typen en doet dus ook type checking met kennis van generics. De compiler compileert de geparameterizeerde typen daarna inderdaad weg omdat de bytecode geen kennis heeft van geparameterizeerde typen (in tegenstelling tot de toekomstige IL van .NET die generics in C# mogelijk gaat maken). Het gaat echter wat ver om dit dan als een preprocessor feature te omschrijven.

[Alarmnummer]

De bytecode heeft wel kennis van geparametriseerde types. Er wordt namelijk wel informatie over de typeparameters in de bytecode opgenomen. Ik geloof dat er een attribuut in de bytecode voor werd 'misbruikt' om extra informatie op te nemen.

[mbravenboer]

Alarmnummer: De bytecode heeft wel kennis van geparametriseerde types. Er wordt namelijk wel informatie over de typeparameters in de bytecode opgenomen. Ik geloof dat er een attribuut in de bytecode voor werd 'misbruikt' om extra informatie op te nemen.

Nou ja, het hangt er vanaf wat je kennis noemt.

De mate van kennis is in ieder geval niet te vergelijken met de IL van .NET. Vanwege backwards gezeik en om de implementatie van JVMs niet verder te compliceren is ervoor gekozen dat de bytecode niet fundamenteel aangepast mag worden om generics mogelijk te maken.

Er schijnt inderdaad wat aan gegevens in attributen meegegeven te worden zodat JVMs met kennis van generics die kunnen gebruiken, maar er is ook vastgelegd dat de JVM deze attributen niet percee hoeft te begrijpen om de bytecode correct uit te kunnen voeren. Het zijn dus extra hints.

Het attributen verhaal is vroeger een van de grote bezwaren van Sun tegen de Microsoft VM geweest, dus het zou wat merkwaardig zijn als ze die nu opeens noodzakelijk maken . Sowieso kan je je afvragen of het nut heeft om iets als een attribuut te representeren als het toch percee begrepen moet worden.

Merk overigens op dat Java bytecode dus altijd al support voor attributen heeft gehad, maar dat je ze in de sourcecode niet kon aangeven: het was puur bedoeld voor compilers en jvms (en eventueel andere tools).

[MSalters]

Goed, ik geloof dat ik een wat onbekend punt heb aangestipt. Het probleem met Checked Exceptions is dat in generieke code je dus compile-time catch specificaties moet genereren.
Dat betekent dat je compile-time moet kunnen bepalen welke exceptions gegooid kunnen worden, en ook hoeveel (om te weten hoeveel catch-clauses je hebt). Omdat je een exception ook via z'n base class moet kunnen vangen, moet je dus feitelijk alle exceptions in een "inheritance forest" onderbrengen, en het aantal unieke base types bepalen.

Abstract voorbeeld: Stel, ik heb een templated functie F, met als template parameter een (non-template) functie G. F roept G aan. Als we F instantieren met een functie foo(), en we hebben CE, dan moet F<foo> dus alle exceptions vangen die foo gooit. Er is geen C++ syntax die dat mogelijk maakt. In C++ is dat ook geen probleem; de gebruiker van F<foo> kent foo, en die kan dus de exceptions van foo afvangen.

Concreet voorbeeld: std::vector<T> roept regelmatig de copy constructor aan van T, zonder te weten welke exceptions deze gooit. Als ik een std::vector<MyClass> kopieer, dan weet ik dat ik exceptions van type MyClass::NoWidgets moet afhandelen, maar Microsoft kan die op geen enkele manier afhandelen.

[EfBe]

MSalters: maar, als iedere method in de api waartegen je praat in je taal T alle exceptions specificeert die hij zou kunnen throwen, kun je wel degelijk die lijst opstellen, al is het complex. Het gaat mis als een of meerdere methods die je gebruikt geen throws lijst hebben.

F<foo> in jouw voorbeeld zou alle exceptions van foo() moeten catchen. In een CE wereld moet foo() een throws clause hebben, dus kan de compiler gemakkelijk checken of jij in F<foo> die ook catched. Echter, met generics kun je ook F<bar> creeeren met hetzelfde template en als bar() een hele andere throws clause heeft, heb je wel degelijk een probleem idd.

throw is toch een C++ construct (optioneel) ? MSVC++ heeft daar geen support voor, dat klopt, zoals naar ik meen, geen enkele C++ compiler.