[Java] wanneer nieuwe exceptie wanneer andere text

[Alarmnummer]

Ik zit al een tijdje met een ontwerp probleem en dat is wanneer je nu een nieuwe exception gaat maken en wanneer je gewoon een algemenere exception gaat vullen met een bericht.

Een van de voordelen van een nieuwe (lees specifiekere) exception is dat je hem specifiek kan afvangen met een try catch en dat kan je niet doen met een algemenere (tenzij je het bericht gaat gebruiken ). Zo gauw je dit wilt doen moet je dus gebruik maken van een nieuwe exception die extends van die algemenere zoals EOFException en IOException.

Maar als je hierin niet geinteresseerd bent, en gewoon wilt weten dat er iets is misgegaan (meestal zo heftig dat doorgaan geen zin heeft) dan heeft het geen nut om een groot aantal exceptions te maken die je nooit gebruikt.

Mijn vraag is dus hoe jullie dit probleem aanpakken.

[traviandus]

De meeste soort exceptions die je zou willen throwen bestaan volgens mij al, bijvoorbeeld de FileNotFoundException of de IllegalArgumentException. Ik heb nog nooit mijn eigen exception gemaakt. Maar soms kan het best handig zijn, bijvoorbeeld een XML parser die ik eens heb gebruikt wierp een (zijn eigen) exception op als hij een fatale fout tegenkwam. In die exceptie zaten dan weer methods om de regel en columnnummer op te vragen. Op die manier kon ik de gebruiker dan netjes naar een editor sturen en de cursor op die regel plaatsen.

[Dash2in1]

Soms als je een eigen klasse maakt maak ik wel eens een eigen Exception..
Eerlijk gezegd zal dit over het algemeen zo zijn omdat ik dan of:
1) specifiek daar een aparte catch voor zou willen
2) geen Exception weet die bij de betreffende situatie goed zou passen (waar er naar alle waarschijnlijkheid wel eentje zal bestaan)

[Tomatrix]

Ik maak zelf veel gebruik van eigen excepties. Erg makkelijk met debuggen, de stacktrace geeft meestal precies aan wat er mis is gegaan.

[Alarmnummer]

Op dinsdag 11 december 2001 12:32 schreef Tomatrix het volgende:
Ik maak zelf veel gebruik van eigen excepties. Erg makkelijk met debuggen, de stacktrace geeft meestal precies aan wat er mis is gegaan.

ik maak meestal ook eigen excepties. Maar ik zal me iets duidelijker proberen te maken aan de hand van het volgende voorbeeld.

Stel ik heb een class HuizenBouwer en deze heeft een methode bouwhuis()throws HuizenBouwException. Nu zijn de stenen op en je zou een HuizenBouwException kunnen opwerpen met daarin het bericht "de stenen zijn op" of je zou een StenenZijnOpException (kind van HuizenBouwException) kunnen opwerpen.

Het zou kunnen voorkomen dat je StenenZijnOpException wilt opvangen om de stenen te bestellen en dan verder te gaan. Daarom is het nuttig om een specifieke exception te maken. Maar als je niet geinteresseerd bent daarin dan is het volgens mij niet nodig om een extra class aan te maken. (En het kunnen er nogal een groot aantal worden).

[drm]

Op dinsdag 11 december 2001 12:41 schreef Alarmnummer het volgende:

[..]

ik maak meestal ook eigen excepties. Maar ik zal me iets duidelijker proberen te maken aan de hand van het volgende voorbeeld.

Stel ik heb een class HuizenBouwer en deze heeft een methode bouwhuis()throws HuizenBouwException. Nu zijn de stenen op en je zou een HuizenBouwException kunnen opwerpen met daarin het bericht "de stenen zijn op" of je zou een StenenZijnOpException (kind van HuizenBouwException) kunnen opwerpen.

Het zou kunnen voorkomen dat je StenenZijnOpException wilt opvangen om de stenen te bestellen en dan verder te gaan. Daarom is het nuttig om een specifieke exception te maken. Maar als je niet geinteresseerd bent daarin dan is het volgens mij niet nodig om een extra class aan te maken. (En het kunnen er nogal een groot aantal worden).

Dan maar veel exceptions, toch? Het ligt er maar net aan hoeveel je programma nodig heeft. In ieder geval zou ik nooit op basis van een string-comparison het type exception bepalen.

Eerder een soort "mainexception" die je dan bijvoorbeeld HuizenBouwException noemt, die een flags-property heeft met voor elke bit een bepaalde betekenis:

code:

try 
{
   // ..
} 
catch ( HuizenBouwException e ) 
{
   System.out.println ( "Huizen bouw fout(en):" );
   if ( e.flags & HuizenBouwer.STENEN_OP )
    System.out.println ( "De stenen zijn op );
   if ( e.flags & HuizenBouwer.BOUWER_DOOD )
    System.out.println ( "De huizenbouwer is dood" );
   System.exit ( -1 );
}

Met op het moment dat je zo'n exception throwt, je aangeeft wat voor exception het is:

code:

throw HuizenBouwException ( HuizenBouwer.STENEN_OP );

gokje

anyhow, hth

<sub>disclaimer:
* drm is geen Java programmeur


edit: even wat duidelijker</sub>

[Alarmnummer]

Op dinsdag 11 december 2001 13:15 schreef drm het volgende:

[..]
In ieder geval zou ik nooit op basis van een string-comparison het type exception bepalen.

vandaar ook de

Eerder een soort "mainexception" die je dan bijvoorbeeld HuizenBouwException noemt, die een flags-property heeft met voor elke bit een bepaalde betekenis:

Als er de stenen op zijn, dan worden stenen besteld, en als er iets anders gebeurd (bv staking) dan kan je die exception gewoon omhoog werpen naar de aanroepende methode.
Je kan dus een specifieke exception pakken en de rest gewoon ergens anders afhandelen.
Dit kan trouwens ook in jouw voorbeeld:

code:

try
{
   HuizenBouwer.bouwHuis();
}
catch(HuizenbouwException e)
{
   if(e.getType()==HuizenBouwer.STENEN_OP)
    HuizenBouwer.bestelStenen();
   else
    throw e;
}

[Tomatrix]

Op dinsdag 11 december 2001 13:28 schreef Alarmnummer het volgende:

Als er de stenen op zijn, dan worden stenen besteld, en als er iets anders gebeurd (bv staking) dan kan je die exception gewoon omhoog werpen naar de aanroepende methode.
Je kan dus een specifieke exception pakken en de rest gewoon ergens anders afhandelen.
Dit kan trouwens ook in jouw voorbeeld:

code:

try
{
   HuizenBouwer.bouwHuis();
}
catch(HuizenbouwException e)
{
   if(e.getType()==HuizenBouwer.STENEN_OP)
    HuizenBouwer.bestelStenen();
   else
    throw e;
}

Het is alleen niet erg netjes om de program flow dmv. excepties te regelen, het heten niet voor niets excepties! Je zou in het stuk code dat deze exceptie werpt al moeten checken of er genoeg stenen zijn.

En in plaats van een constante met het type zou ik gewoon een aparte klasse maken die afgeleid is van HuizenBouwException ofzo (maar dan zonder engels/nederlands door elkaar )

[Alarmnummer]

Maar de vraag is of het nut heeft om een hele lading exceptions te maken (die je niet specifiek gaat afvangen). Het lijkt mij dan het meest voor de hand liggend om de aard van de melding in de message te stoppen en alleen een HuizenbouwException op te werpen.

Vind het jammer dat daar vrij weinig info over is. Heb wel aantal artikels doorgelezen op javaworld en javalobby en heb stuk gelezen van bruce eckel waarin hij alleen nog maar hidden exception wou hebben

[drm]

Tomatrix:
Het is alleen niet erg netjes om de program flow dmv. excepties te regelen, het heten niet voor niets excepties! Je zou in het stuk code dat deze exceptie werpt al moeten checken of er genoeg stenen zijn.

En in plaats van een constante met het type zou ik gewoon een aparte klasse maken die afgeleid is van HuizenBouwException ofzo (maar dan zonder engels/nederlands door elkaar )

goed punt.
Dat is dus ook meteen het antwoord:

samenvattend:
• Voor het geval je een "fout" krijgt waarbij de stenen bijvoorbeeld op zijn en er nieuwe besteld moeten worden spreken we van if {} else {} structuren
.
• Voor het geval je een "fout" krijgt, die door een ander object opgelost moet worden, moet het object waarin de fout gemaakt wordt, het andere object wat het op kan lossen aanroepen. Als dat niet kan, is er iets mis met je ontwerp.
.
• Voor het geval je een exceptie hebt, waarbij een object ophoudt met functioneren omdat hij iets tegenkomt waar hij niet mee verder kan, en geen objecten kent die het voor hem op kunnen lossen spreken we over throw, try{} catch {}, structuren

[Alarmnummer]

Even een voorbeeld om aan te tonen dat jullie oplossing niet gaat werken.

code:

if(a==0)
{
  ... niet rekenen
}
else
{
  b = 10/a;
}

Niemand gaat alles controleren. Alles controleren is gewoon niet mogelijk en je krijgt ongelovelijke lelijke code. Misschien is in dat opzicht 'de stenen zijn op' voorbeeld niet echt geschikt (had wel via normale if afgevangen kunnen worden). Maar stel dat de metselaar gewond raakt (iets waar je niet steeds op loopt te controleren) dan werp je wel een exception op.

[drm]

Op dinsdag 11 december 2001 15:39 schreef Alarmnummer het volgende:
Even een voorbeeld om aan te tonen dat jullie oplossing niet gaat werken.

code:

if(a==0)
{
  ... niet rekenen
}
else
{
  b = 10/a;
}

Niemand gaat alles controleren. Alles controleren is gewoon niet mogelijk en je krijgt ongelovelijke lelijke code. Misschien is in dat opzicht 'de stenen zijn op' voorbeeld niet echt geschikt (had wel via normale if afgevangen kunnen worden). Maar stel dat de metselaar gewond raakt (iets waar je niet steeds op loopt te controleren) dan werp je wel een exception op.

Klopt, maar je moet dus heel duidelijk zien te krijgen wanneer je over een gewone controlstructure praat of over een exception. En dan is het aan jou om te beslissen

Alles throwen is minstens zo lelijk

heeft simpelweg te maken met het ontwerp van je programma.

[Alarmnummer]

Hierdoor is je code niet 'vervuild' met uitzonderlijke gevallen.

[Tomatrix]

Op dinsdag 11 december 2001 14:12 schreef Alarmnummer het volgende:
Maar de vraag is of het nut heeft om een hele lading exceptions te maken

Heb ik al antwoord op gegeven, mijns inziens heeft het nut, zeker om dat je niet verplicht bent de sub klasse op te vangen, maar ook gewoon een superclass kan catchen (wanneer je niet geinteresseerd bent in de precieze exceptie)

[drm]

Op dinsdag 11 december 2001 15:50 schreef Alarmnummer het volgende:
Hierdoor is je code niet 'vervuild' met uitzonderlijke gevallen.

bingo. Exception = uitzonderlijke gevallen.

Dus, even back to the start: Als je veel uitzonderlijke gevallen gaat krijgen, kan je je afvragen of ze nog wel zo uitzonderlijk zijn.
Zo ja: dan moet je een hoop Exceptions coden, denk ik.

[Alarmnummer]

Op dinsdag 11 december 2001 15:50 schreef drm het volgende:
Alles throwen is minstens zo lelijk

Ben ik 100% met je eens. Je moet inderdaad geen exceptions gebruiken als flow control. Maar het was een voorbeeld. Soms krijg je in je programma nou eenmaal exceptions (HandVanMetselaarLigtErAfException) en daar ga je nu eenmaal niet op lopen controleren. Je zorgt ervoor dat iedere methode een throws HuizenBouwException kan werpen zodat je zelf kan kiezen op welk niveau je het gaat afhandelen. De vraag is wanneer je een
new HandVanMetselaarLigtErafException gaat opwerpen en wanneer je een
new HuizenBouwException("hand van metselaar ligt eraf") gaat opwerpen.

Je gebruikt een specifiekere exception (HandVanMetselaarLigtErAfException) als je die wilt opvangen en er iets mee wil doen. Bijvoorbeeld

code:

try
{
}
catch(HandVanMetselaarLigtErafException e)
{
  ...lijm hand er weer op en ga verder bouwen.
}

Maar dan moeten objecten op heel laag nivea (bv.. Stenen.plaatsSteen al gemaakt worden op dat er op hoger niveau wel eens iets bijzonders mee gedaan kon worden. En dat is een beetje het probleem. Wanneer specifiekere exception en wanneer een iets algemenere.