[alg] checked exceptions

[Alarmnummer]

Toen ik checked exceptions tegenkwam bij java was ik in het begin er helemaal verliefd op. Je kon eenvoudig afdwingen dat de exceptie afgevangen moet worden, of dat hij verder gepropageerd moet worden. Bij het uitkomen van c# (en .NET) zag ik dat daar geen checked exceptions aanwezig waren en vond dit een groot min-punt van de taal. Op javalobby kom je natuurlijk de bijbehorende flames en trolls tegen dat de meest voorkomende fout op het .NET platform de unhandeledException zal zijn.

Maar ik begin steeds anders tegen de checked exception aan te kijken. Veel generieke bibliotheken zijn niet gebouwd voor een specifieke checked exception (alhoewel je met wat generics wel een eind kan komen ) en hierdoor kan je 2 dingen doen.
-copies maken van die libraries en dan checked exceptions toevoegen.
-de checked exception wrappen in een unchecked exception en die dan opwerpen. Hierdoor kan je dus uitstekend gebruik maken van die library.

Ik hoef niet uit te leggen dat de 1e optie niet echt geweldig is, en daardoor kom je dus uit bij de 2e. De vraag blijft dan hoe belangrijk die checked exception blijft, op het moment dat je hem gaat wrappen in een unchecked exception.

Wat vinden jullie van checked exceptions? En mensen die geen checked exceptions hebben (c++, c#, delphi), hoe gaan jullie om met het afvangen van exceptions?

ps
Ik zie trouwens vaak als argument tegen checked exceptions staan, dat mensen de checked exception gaan afvangen zonder er iets mee te doen.

code:

try{ 
   ....
}catch(CheckedException e){}

Dit vind ik dus een enorm slap argument. Als mensen zo dom zijn, dan moeten ze gewoon niet gaan programmeren en ik heb geen zin om daar mee lastig gevallen te worden.

[ Voor 3% gewijzigd door Alarmnummer op 07-08-2003 11:12 ]

[mbravenboer]

Op zich zijn checked exceptions niet zo erg duivels, alleen overmatig gebruik ervan is slechts. Je ziet teveel dat programmeerfouten een checked exception opleveren en dat is dus niet goed. Alleen in situaties waar (in een 'correct' programma) een incorrecte situatie gecorrigeerd moet worden omdat een operatie mislukt door externe factoren, zou gebruikt moeten worden gemaakt van checked exceptions.

Zie ook Effective Java:
http://java.sun.com/docs/books/effective/toc.html

Overigens is het natuurlijk een blunder dat een RuntimeException een subclass is van Exception.

[whoami]

Misschien handig om eens een oudere thread van je op te dissen:
[rml][ c#] waarom geen checked exceptions??[/rml]

[Alarmnummer]

mbravenboer schreef op 07 August 2003 @ 11:19:
Op zich zijn checked exceptions niet zo erg duivels, alleen overmatig gebruik ervan is slechts. Je ziet teveel dat programmeerfouten een checked exception opleveren en dat is dus niet goed. Alleen in situaties waar (in een 'correct' programma) een incorrecte situatie gecorrigeerd moet worden omdat een operatie mislukt door externe factoren, zou gebruikt moeten worden gemaakt van checked exceptions.

Ik moet zo nu en dan nog wel eens een checked exception wrappen in een unchecked exception om gebruik te kunnen maken van een bepaalde library. Of kijk anders maar eens wat er gebeurd als je bv gebruik maakt van een visitor (die geen checked exception heeft) en bij een visit-methode je wel ineens een checked exception voor de kiezen krijgt. Op dat punt wrap ik ook die checked exception.

Overigens is het natuurlijk een blunder dat een RuntimeException een subclass is van Exception.

Het had misschien wel gekunt als Exception 2 kinderen had gehad, Checked en Unchecked... Maar verder ben ik het met je eens dat het een rare constructie is, want je zegt inwezen dat iedere unchecked exception ook een checked exception is.

whoami schreef op 07 August 2003 @ 11:23:
Misschien handig om eens een oudere thread van je op te dissen:
[rml][ c#] waarom geen checked exceptions??[/rml]

Ojee, ik begin echt oud te worden

[ Voor 16% gewijzigd door Alarmnummer op 07-08-2003 11:37 ]

[EfBe]

Bekijk deze messages maar:
http://www.google.com/gro...unnerson&lr=&num=30&hl=en

Van Eric Gunnerson, lid van C# core team. Hij legt het uit waarom checked exceptions niet zijn toegelaten tot .NET, en ik ondersteun het van harte. Checked exceptions zijn een fout middel, ze definieren nl. implementatie-gerichte aspecten in de interface terwijl dat niet aan de orde is in een interface.

(ps, let niet op mij in die threads )

[ Voor 8% gewijzigd door EfBe op 07-08-2003 19:12 ]

[JohanDM]

Checked exceptions hebben weinig echte voordelen, of laat ik het zo stellen:
1) Het grootste voordeel van checked exceptions is dat je verplicht bent de exception af te handelen
2) Het grootste nadeel van checked exceptions is dat je verplicht bent de exception af te handelen
Naar mijn ervaring moet je exceptions alleen opvangen als je ze kunt corrigeren of je informatie over de exception kan toevoegen of aan de eindgebruiker tonen. In alle andere situaties, laat je ze best ongemoeid.
Het ergste wat je kan doen met een exception is ze catchen en er verder niets mee doen.
Helaas veroorzaakt het checked exception principe juist dit coderings gedrag, namelijk het schrijven van lege catch blokken (omdat je moet) en dat je deze later vergeet in te vullen.
Dit is veel erger dan het vergeten van een catch blok. Ik verklaar: als je bij unchecked exceptions een catch blok vergeet, zal de runtime je programma stoppen - het crasht - dit valt op, en is vrij goed op te sporen dankzij de stacktrace die zo'n exception meedraagt, als een checked exception echter wordt afgevangen met een leeg catch blok, kunnen er fouten in het programma zitten, zonder dat je daar ooit iets van ziet, zonder dat je een trace hebt van waar de fout zich zou kunnen voordoen.

[alienfruit]

Ik vind gewoon als je een exception veroorzaakt dat je als programmeur gewoon dood moet worden geslagen met van die irritante exceptions tot dat het probleem is opgelost

Zal het maar niet hebben over de casatrophic failures in Windows soms

[Eelis]

.

[ Voor 116% gewijzigd door Eelis op 18-02-2015 19:58 ]

[Soultaker]

Eelis schreef op 07 August 2003 @ 22:11:
De copy constructor van een container roept logischerwijs de copy constructor van het opgeslagen type aan (om de opgeslagen instanties te kopieren). Echter, in een generieke container is het type van de opgeslagen objecten geparameteriseerd, en is voor de auteur van de container dus niet bekend welke exceptions gethrowd kunnen gaan worden. Wat zou in een CE model de throws specificatie van de copy constructor van de generieke container moeten zijn?

Waarschijnlijk zou je dan een constructie moeten hebben zodat je aan de exception specification kan refereren, zodat je kan stellen dat de constructor dezelfde exceptions throwed.

Edit:
Hoe zit het eigenlijk met virtual calls? Als f() een virtual call pleegt wordt pas at runtime bekend bij welke functie die aanroep terecht komt, terwijl die mogelijke functies verschillende exceptions zouden kunnen throwen. Wat is de throws specificatie van f()?

Volgens mij is het in Java zo dat je een functie niet kan overriden met een andere exception specification (net zoals je 'm geen ander return type kan geven). Correct me if I'm wrong.

[Erkens]

Alarmnummer schreef op 07 August 2003 @ 11:11:

ps
Ik zie trouwens vaak als argument tegen checked exceptions staan, dat mensen de checked exception gaan afvangen zonder er iets mee te doen.

code:

try{ 
   ....
}catch(CheckedException e){}

Dit vind ik dus een enorm slap argument. Als mensen zo dom zijn, dan moeten ze gewoon niet gaan programmeren en ik heb geen zin om daar mee lastig gevallen te worden.

ehm? in sommige situaties heeft het geen nut om iets met die exception te doen, zoals bijvoorbeeld bij het sluiten van een socket om maar iets te noemen
Waarom zou ik daar iets in de body moeten zetten dan?

[kvdveer]

Soultaker schreef op 07 August 2003 @ 22:50:
Volgens mij is het in Java zo dat je een functie niet kan overriden met een andere exception specification (net zoals je 'm geen ander return type kan geven). Correct me if I'm wrong.

You're right. De throws clause is gewoon een onderdeel van de functie identificatie, net als inderdaad het returntype en of 'ie static is. Je kunt er op lagere niveau's wel exceptions aan toe voegen.

Ik vind zelf dat checked exceptions naar mijn smaak in java nèt te vaak worden gebruikt. Er zijn gewoon situaties waar ik zeker weet dat een exception niet plaats gaat vinden. Die handel ik dan af als catch(EenOfAndereException) {} // zou niet moeten gebeuren.
Ik ben er een voorstander van als de java-syntax uitgebreid zou worden met iets als

Java:

try 
{
  // doe iets 
} 
ignore(IOException)
catch (NullPointerException e)
{
  UI.Fatalmessage("Er is iets vreselijk mis gegaan. " +
  "Uw vrouw lijkt u verlaten te hebben (wife = null)");
}

[NakedOne_NL30]

Erkens schreef op 07 augustus 2003 @ 22:53:
[...]


ehm? in sommige situaties heeft het geen nut om iets met die exception te doen, zoals bijvoorbeeld bij het sluiten van een socket om maar iets te noemen
Waarom zou ik daar iets in de body moeten zetten dan?

Daar is het idd niet verplicht (natuurlijk wel ff commentaar bij zetten), maar het gaat echt om het weggooien van 'waardevolle' exceptions.

[edit]
dit is gepost door alarmnummer die ff bij nakedone op verjaardagsvisite is.

[ Voor 10% gewijzigd door NakedOne_NL30 op 08-08-2003 02:26 ]

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 19:58 ]

[Alarmnummer]

Eelis schreef op 08 August 2003 @ 02:51:
[...]
Om wat voor operatie het ook gaat, de caller bepaalt of het mislukken van die operatie afhandeling vereist.

Sommige exceptions kan je niet afhandelen omdat het systeem in een inconsistente toestand achterblijft (bv een nullpointer fout of een assert fout).

Je kunt als thrower dus geen onderscheid maken tussen waardevolle en niet waardevolle exceptions, en als je dus per se in alle gevallen catch(X){} wil voorkomen zul je overal NCE's moeten gebruiken.

Iedere exception is waardevol, maar sommigen zijn wel afhandelbaar. Stel dat ik een file ga saven en ik moet een IOException afvangen. Dan kan ik ervoor kiezen om een dialoog te laten zien met een foutmelding of bv nog een keer proberen. Ik weet bij een IOException dat ik alles weer op de goeie rails kan krijgen. Maar bij een NullPointerException kan ik dit bv niet garanderen.

[MSalters]

Eelis schreef op 07 August 2003 @ 22:11:
Hoe zit het eigenlijk met virtual calls? Als f() een virtual call pleegt wordt pas at runtime bekend bij welke functie die aanroep terecht komt, terwijl die mogelijke functies verschillende exceptions zouden kunnen throwen. Wat is de throws specificatie van f()?

De throw specificatie van een overrider moet een subset zijn van de base functie; dit mag natuurlijk de lege subset zijn of de identieke set van excepties. Tijdens de compilatie van de overrider moet sowieso worden bepaald wat de base functie is; de extra check is daar eenvoudig in te voegen.

[MSalters]

Soultaker schreef op 07 August 2003 @ 22:50:
-----------------------------------------------------------------
Eelis schreef op 07 August 2003 @ 22:11:
De copy constructor van een container roept logischerwijs de copy constructor van het opgeslagen type aan (om de opgeslagen instanties te kopieren). Echter, in een generieke container is het type van de opgeslagen objecten geparameteriseerd, en is voor de auteur van de container dus niet bekend welke exceptions gethrowd kunnen gaan worden. Wat zou in een CE model de throws specificatie van de copy constructor van de generieke container moeten zijn?

----------------------------------------------------------------

Waarschijnlijk zou je dan een constructie moeten hebben zodat je aan de exception specification kan refereren, zodat je kan stellen dat de constructor dezelfde exceptions throwed.

Dat is de voor de hand liggende optie. Het probleem daarmee is dat zo'n expressie extreem complex kan worden. Zelfs als de gebruiker iets redelijks kan opschrijven is het nog maar de vraag of de compiler er iets mee kan.

Een (C++) voorbeeld: Stel dat class X een member X::foo(int) heeft met een overload X::foo(int) const. Bovendien is er een X::foo( MyString ) zonder const overload. Die drie hebben elk een verschillende exception specification. Nu heb ik een functie bar< T, U > (T const& t ) die de functie t.foo( U() ) aanroept. Als ik die instantieer met T==X roep ik natuurlijk een X::foo() aan. In de exception specification van bar<T,U> moet daar dus iets van terugkomen, maar wat precies?

Mijn gok wordt iets van throw( try(T::foo(U) const) ). Het eerste probleem is U==unsigned int. Dat is een redelijk type, en (unsigned int)0 is perfect acceptabel voor T::foo(int) const. De throw specificatie boven suggereert alleen dat je de exception specifcation try(X::foo(unsigned int) const) gebruikt.

Bovendien is het erg makkelijk om de exceptions van de copy ctor van MyString te vergeten. Moet de compiler daar een error op moeten geven?

[mbravenboer]

The Trouble with Checked Exceptions, A Conversation with Anders Hejlsberg, Part II by Bill Venners with Bruce Eckel.

(Artima is een waardevolle site voor in je bookmarks).

[Alarmnummer]

Artima staat er al een lange tijd in, maar als ik eerlijk ben kom ik na die verbouwing van zijn site er nauwelijks meer.

Ik zal het artikel eens doorlezen, alhoewel me bij staat dat ik ook al een keer iets soortgelijks voor de kiezen heb gehad.

[alienfruit]

Anders Hejlsberg is een toffe gast!
Een van de redenen waarom .NET framework zoveel op VCL lijkt komt volgens mij grotendeels door Anders, gezien hij zowel lead architect bij Borland voor Delphi was al lead architect C# bij Microsoft. Heb grote bewondering voor de gast, veelste slim

[ Voor 79% gewijzigd door alienfruit op 19-08-2003 12:43 ]

[Alarmnummer]

Hmm.. als ik hem had moeten beoordelen op alleen Delphi, dan was ie er niet al te best vanaf gekomen. Ik vind de taal in zijn geheel nogal rommelig (en dan spreek ik dus niet over de api`s van delphi).

[ Voor 3% gewijzigd door Alarmnummer op 19-08-2003 12:56 ]

[whoami]

Alarmnummer schreef op 19 August 2003 @ 12:56:
Hmm.. als ik hem had moeten beoordelen op alleen Delphi, dan was ie er niet al te best vanaf gekomen. Ik vind de taal in zijn geheel nogal rommelig (en dan spreek ik dus niet over de api`s van delphi).

Delphi gebruikt Object Pascal, dat gebaseerd is op Pascal.
Je kan Hjelsberg dus niet afrekenen op het feit dat jij Pascal rommelig vind, want ik denk niet dat hij daar aan meegewerkt heeft. De VCL daarentegen, daar zal hij wel aan meegewerkt hebben.

offtopic:
Trouwens, Pascal is helemaal geen rommelige taal. 't Is wel een aanpassing natuurlijk als je C-like syntax talen gewend bent).

[alienfruit]

Nou ik vind Delphi prima werken (stuk beter dan VB) overigens heeft Hjelsberg inderdaag niet meegewerkt aan de taal Pascal, maar wel Object Pascal en de VCL.

offtopic:
Trouwens, Pascal was ook één taal om het programmeren te leren. Waar nu Java voor wordt gebruikt op de scholen/universiteiten werd er eerder altijd Pascal gebruikt. Heb zelf nog wel een paar dictaten over Pascal liggen.

[whoami]

offtopic:
Ga Delphi nu aub niet met VB gaan vergelijken

Verder ging dit topic over Checked Exceptions en niet over de verwezenlijkingen van deze of gene. Het topic ging ook niet over Delphi of over VB, dus, misschien kunnen we terug on-topic gaan.

[Alarmnummer]

whoami schreef op 19 August 2003 @ 14:28:
Delphi gebruikt Object Pascal, dat gebaseerd is op Pascal.
Je kan Hjelsberg dus niet afrekenen op het feit dat jij Pascal rommelig vind, want ik denk niet dat hij daar aan meegewerkt heeft. De VCL daarentegen, daar zal hij wel aan meegewerkt hebben.

Trouwens, Pascal is helemaal geen rommelige taal. 't Is wel een aanpassing natuurlijk als je C-like syntax talen gewend bent).[/offtopic]

Pascal kan je niet vergelijken met Delphi. Pascal is imho fraai opgezet, tenslotte is het ook opgezet om studenten te laten programmeren. Object pascal is idd niet echt geweldig, maar Delphi vind ik erg rommelig.

[offtopic]
houd er nu ook over op

[ Voor 4% gewijzigd door Alarmnummer op 19-08-2003 15:16 ]

[mbravenboer]

M'n linkje was echt goed bedoeld

[whoami]

mbravenboer schreef op 19 August 2003 @ 15:22:
M'n linkje was echt goed bedoeld

Het is ook een leuk linkje.
'k Moet die site nog altijd adden bij m'n favo's.

[Verwijderd]

mbravenboer schreef op 19 augustus 2003 @ 15:22:
M'n linkje was echt goed bedoeld

Dat is ie zeker, ik vind die site erg interessant.
Hetgeen of check exceptions wel of niet goed zijn heeft bij mij ook altijd wat vragen achtergelaten, zoals Alarmnummer zelf ook al in dit topic aangeeft. Ik heb al meedere websites bezicht die hierop ingingen, maar met er tot heden nog steeds niet helemaal uit wat ik zelf nou het beste vind. De punten voor unchecked exceptions zoals die gegeven worden in C# articles komen wel altijd goed naar voren, maar alsnog kan ik zelf nog steeds geen conclusie trekken. Die link die jij gaf is wel degelijk nuttig voor mij, ik vind het altijd leuk om eens goed te kijken wat ik het beste kan doen.