[Java] Exception Design.

[Alarmnummer]

Voor de duidelijkheid, ik weet hoe exceptions werken maar deze topic heb ik geplaatst omdat ik geinteresseerd ben in het ontwerpen van exceptions. Bijvoorbeeld: wanneer maak je een exception hidden en wanneer niet (een equals methode die mag geen exceptions opwerpen, dus dan maak je ze hidden). Wanneer maak je een nieuwe classe aan en wanneer gebruik je een oude classe en alleen door de exception message laat je zien wat er is gebeurd. Het voordeel van een nieuwe classe is dat je die heel specifiek kan afvangen en de rest kan laten verder gaan. Het lijkt me interessant hoe de rest van de java programmeurs met exceptions omgaat.

[mbravenboer]

Hum tja...

1. Exception gooi ik altijd zover mogelijk door. Meestal komt dit neer op de initiele plek waar de gebruiker een actie ging uitvoeren.

2. RuntimeExceptions gebruik ik alleen voor situaties die duidelijk een ongeldige status van een programma als oorzaak hebben. Bijvoorbeeld: ik gebruik veel XML files om zaken te configureren in applicaties. Deze zitten in een jar bij de class files. Als deze files niet gevonden worden (IOException) of een parse exception optreedt (SAXException oid) dan verpak ik deze in een RuntimeException. Dit is namelijk een fout die niet voor zou moeten kunnen komen.

3. Over het algeem maak ik voor een API een superklasse voor alle foutmeldingen (IOException is daar een voorbeeld van). Alle specifieke Exceptions maak ik aparte subclasses daarvan (voor zover de applicatie geholpen is met een specifieke exception). Als een bepaald onderdeel nu veel verschillende exceptions kan gooien, dan kan je die de superklasse Exception laten gooien. Als een applicatie dus aan de hand van de inhoud van een exception een andere aktie zou moeten kunnen ondernemen dan maak ik er meestal een aparte subklasse van (voorbeeld: FileNotFoundException).

4. Gebruik zoveel mogelijk de geneste Exceptions in 1.4.0 . Bij een Exception kan je een cause opgeven. Als je een exceptie wilt doorgooien in een andere vorm kan je zo toch nog de originele exceptie laten meegaan.

5. Verder heb ik een gelikt standaard dialoogje met alle benodigde exception info: duidelijk scherm voor de gebruiker, meer info voor een ontwikkelaar, stack trace in een JTable ( ) en de mogelijkheid om de exception in XML formaat via een talk-back functie naar de ontwikkelaar te mailen . Niet echt relevant, maar wel leuk .
6. Als items niet aanwezig zijn in verzamelingen etc return ik ook meestal niet null. Ik vind het vervelend om steeds op null waarden te moeten controleren. Eigenlijk vind ik het gewoon een fout als een item niet aanwezig is. Daarom gebruik ik daarvoor een generieke NotFoundException. Dit gebruik voor TextI18nBundles, ResourceManagers, eigen Collections enz. Als je er niet zeker van bent dat een item aanwezig is, zou je dit gewoon eerst moeten controleren.

[Alarmnummer]

Propageer jij ook hidden exceptions?

[mbravenboer]

Alarmnummer: Propageer jij ook hidden exceptions?

Je bedoelt RuntimeExceptions? Ik neem ze over het algemeen niet op in de throws clause, maar als het logisch is dat een Exception gethrowd kan worden doe ik dit wel.

Ik heb bijvoorbeeld een ResourceManager. Die laadt resources . Als een resource niet is gevonden gooit deze een (runtime) NotFoundException. Deze neem ik niet op in de throws clause omdat ik vind dat je daar geen rekening mee hoeft te houden. Als de fout echter te verwachten is neem ik hem wel op, of maak ik er een niet run-time exception van.

[mbravenboer]

Ikke kwam dit tegen:

http://developer.java.sun.com/developer/technicalArticles/Programming/exceptions/

[Alarmnummer]

Thanx

[Alarmnummer]

Op dinsdag 02 oktober 2001 19:32 schreef mbravenboer het volgende:
Ikke kwam dit tegen:

http://developer.java.sun.com/developer/technicalArticles/Programming/exceptions/

Ben het nu even aan het lezen en het is een heel aardig stukje.

[mbravenboer]

Alarmnummer: Ben het nu even aan het lezen en het is een heel aardig stukje.

Yep inderdaad, vond het ook wel aardig . Bij de resources staan ook nog wat stukjes, vooral de Javaworld artikelen zijn wel goed.

[Alarmnummer]

Op maandag 01 oktober 2001 12:02 schreef mbravenboer het volgende:

[..]

Je bedoelt RuntimeExceptions? Ik neem ze over het algemeen niet op in de throws clause, maar als het logisch is dat een Exception gethrowd kan worden doe ik dit wel.

Ik heb bijvoorbeeld een ResourceManager. Die laadt resources . Als een resource niet is gevonden gooit deze een (runtime) NotFoundException. Deze neem ik niet op in de throws clause omdat ik vind dat je daar geen rekening mee hoeft te houden. Als de fout echter te verwachten is neem ik hem wel op, of maak ik er een niet run-time exception van.

Het enigste waar dan wel rekening mee gehouden moet worden is dat op een bep niveau die RuntimeException toch af gevangen moet worden, anders blijft ie zich maar omhoog werken.

Lijkt wel een beetje op c#, daar hoef je ook geen exceptions te propageren (is gedaan om visual basic mensen rustig te houden). Meest voorkomende fout gaat daar ook worden : UnhandledException

[edit] typo`s

[commentaar] loopt bij iedereen het forum een beetje verot?

[vraag]hoe kan ik iets bold maken? <b>tekst</b> werkt niet

[mbravenboer]

Alarmnummer: Het enigste waar dan wel rekening mee gehouden moet worden is dat op een bep niveau die RuntimeException toch af gevangen moet worden, anders blijft ie zich maar omhoog werken.

Klopt, meestal vang ik op bepaalde plekken alle Exceptions op. Meestal komt dit neer op een opvang in een actionPerformed of een andere user-actie.

Lijkt wel een beetje op c#, daar hoef je ook geen exceptions te propageren

Klopt, maar daar geldt het voor alle exceptions... Lelijk dus. Ik gebruik het ook alleen voor situaties die eigenlijk absoluut niet voor kunnen komen en een volledige illegale toestand van de applicatie betekenen.

[commentaar] loopt bij iedereen het forum een beetje verot?

Ja, de laate dagen is het ontzettend prut. Ze weten niet echt waaraan het ligt...

[vraag]hoe kan ik iets bold maken? <b>tekst</b> werkt niet

Zie de faq: [ ipv < : [ b]... [ /b] en [code ] ... [ /code] etc

[Alarmnummer]

Klopt, meestal vang ik op bepaalde plekken alle Exceptions op. Meestal komt dit neer op een opvang in een actionPerformed of een andere user-actie.

Jij weet dat je RuntimeExceptions op moet vangen, maar de kans is groot dat andere mensen ook met die sources aan de slag moeten en hoe ga je duidelijk maken dat er stiekum zo`n RuntimeException opgeworpen kan worden?

[Alarmnummer]

Wat ben ik nou aan het kwekken. RuntimeExceptions zoals die NullPointerException die ga je ook niet overal lopen afvangen..

[mbravenboer]

Alarmnummer: Jij weet dat je RuntimeExceptions op moet vangen, maar de kans is groot dat andere mensen ook met die sources aan de slag moeten en hoe ga je duidelijk maken dat er stiekum zo`n RuntimeException opgeworpen kan worden?

Das een goed punt, maar ja. Je weet het ook niet van NullPointers, IllegalArgumentException, ClassNotFoundExceptions enz...

Als het een fout is die veroorzaakt zou kunnen worden door een programmeursfout of een fout in de huidige toestand van het programma dan maak ik daar een normale Exception van.

Als dit het om extreme gevallen gaat waarvan je in feite weet dat het onmogelijk kan voorkomen, dan maak ik er een RuntimeException van en geef wel in eerste methode aan dat deze gegooid kan worden. In de latere methoden doe ik dat niet en dat kan dus problemen op leveren.

Maar ja, als je alles gaat opgeven wordt het een onmogelijke zaak. Zoals ik al zei gebruik ik veel XML en XSL als ondersteuning. Als ik dan beide gebruikt zou ik dit moeten gooien:

Voor parsen en inlezen:
- ParserConfigurationException
- IOException
- SAXException

Voor url resources:
- MalformedURLException
- NullPointerException

Voor transformeren:
- TransformerConfigurationException
- TransformerException

Dat zijn er dus 7! Uiteraard zou je dit kunnen inpakken in 1 generieke Exception voor dat component of package, maar omdat het een onderdeel is van de applicatie die gewoon in een jar zit, vind het niet nodig om als programmeur met deze toestand rekening te gaan houden. Je gaat ook geen rekening houden met alle mogelijke missende klassen...

Kortom: per geval beoordeel ik het .

[mbravenboer]

Alarmnummer: Wat ben ik nou aan het kwekken. RuntimeExceptions zoals die NullPointerException die ga je ook niet overal lopen afvangen..

idd, das ook ongeveer de strekking van mijn verhaal

[Alarmnummer]

Zat net nog even op de sun site te kijken bij nieuwe features van jdk1.4 en exceptions, na aanleiding van een opmerking die je laatst had geplaatst. En je kunt dus heel eenvoudig een exception wrappen in een andere exception. Heb nu even de vrijheid om code helemaal te gaan opschonen en zal dit ook gaan implementeren, zodat je alle exception info houd. Heb je verder nog een paar tips of ideeen?

[mbravenboer]

mbravenboer: 4. Gebruik zoveel mogelijk de geneste Exceptions in 1.4.0 . Bij een Exception kan je een cause opgeven. Als je een exceptie wilt doorgooien in een andere vorm kan je zo toch nog de originele exceptie laten meegaan.

.

Die zou ik dus inderdaad heel goed gebruiken. Erg makkelijk. Verder heb ik niet echt tips voor exception handling... Ik vind een talk-back functie zelf erg belangrijk en makkelijk (gebruik zelf een fraaie GUI + mailtje in XML formaat naar ontwikkelaar voor alle exceptions).

Verder is het ook wel belangrijk om een beetje aan de uniekheid van een fout te denken: hoe kan je op een fout reageren? Met een IOException kan je niet veel. Met een exception met wat meer context kan je meer. Het is dus wel handig om exceptions in te pakken in een betekenis of er zelfs unieke ids ofzo voor te gebruiken.

Internationalisatie van exception messages is ook wel handig.

[Alarmnummer]

Wat bedoel je met een talk-back functie?

Ik heb het schermpje van je gezien voor het zichtbaar maken van een exception en die ziet er leuk uit. Maar ik heb bewust niet gekozen om exceptions aan (voornamelijk) niet wetende gebruikers te laten zien. Alle exceptions (lees de volledige Sysem.out en System.err stream) worden gelogd in een file. En die kan ik later wel bekijken. Er zit gelukkig nog geen handige mail functie op

[mbravenboer]

Alarmnummer: Wat bedoel je met een talk-back functie?

Ik bedoel daarmee inderdaad het mailen van een foutmelding. Het is zo waardeloos als je te horen krijgt dat iets niet werkt, zonder dat ze aan kunnen wijzen wat er niet werkt... Een exception kan vaak genoeg informatie verschaffen .

Ik heb het schermpje van je gezien voor het zichtbaar maken van een exception en die ziet er leuk uit. Maar ik heb bewust niet gekozen om exceptions aan (voornamelijk) niet wetende gebruikers te laten zien.

Klopt wel een beetje. Ik laat daarom ook alleen de message van een exception, een extra informatie string die je opgeeft als je de dialoog aanmaakt aan het type van de fout zien (dat laatste is misschien teveel van ut goede). Als je meer info wilt kan je de stacktrace bekijken in een nieuwe dialoog in (sinds kort) een table.

Verder kan de gebruiker voor mailen kiezen en eventueel wat extra info aangeven over wat hij aan het doen was toen de fout ontstond. Daarna krijg ik alle info over de fout binnen...

Alle exceptions (lees de volledige Sysem.out en System.err stream) worden gelogd in een file. En die kan ik later wel bekijken.

Das ook wel handig. Meestal kost het mij echter veel tijd om bij klanten langs te gaan. Daarom is het handig als ik thuis de zaak zonder verder gedoe kan herstellen en dan een update kan sturen .

Er zit gelukkig nog geen handige mail functie op

Hehe . Vroeger kreeg ik ook wel vrij veel meldingen, maar tegenwoordig is het maar zeer sporadisch en is er dan ook wel echt iets aan de hand .

[Alarmnummer]

Mijn programma`s bevatten geen errors, de gebruikers drukken alleen op de verkeerde knoppen

[mbravenboer]

Alarmnummer: Mijn programma`s bevatten geen errors, de gebruikers drukken alleen op de verkeerde knoppen

idd, gebruikers zijn stom

[Alarmnummer]

Op dinsdag 02 oktober 2001 21:39 schreef mbravenboer het volgende:

[..]

idd, gebruikers zijn stom

Ik werk voor 2 opdracht gevers. Bij de RuG werk ik nu vast (zie topic 'Wat verdient een Java Programmeur') en klus zo nu en dan bij voor een jong bedrijfje wat software schrijft voor de timmerindustrie. Ik ben al lang blij dat ik niet met al die gebruikers hoef te praten om daar alle info uit los te krijgen. Soms is het lastig om ze uit te leggen wat je precies bedoelt. Ben blij dat ik geen tussen persoon ben

[The - DDD]

Ah joh gewoon op je hoogste niveau in je programma code het volgende plaatsen om je runtimeexceptions die toch niet voor kunnen komen op te vangen:

code:

catch(Exception e)
{
   JOptionPane.showMessageDialog(
     null, "Gefeliciteerd, je hebt de boel dus toch/n"
       + "dusdanig kunnen vernagelen dat het niet/n"
       + "meer te herstellen is./nAl je werk wordt/n"
       + "niet, ik herhaal, niet opgeslagen./n/n"
       + "Fijne dag verder.",
     "Je doet me versteld staan.",
     JOptionPane.INFORMATION_MESSAGE);

   System.Exit(0);
}

Lachen als het iemand dan toch een keer lukt om dat venstertje te zien...

[Alarmnummer]

Op woensdag 03 oktober 2001 00:37 schreef The - DDD het volgende:
Ah joh gewoon op je hoogste niveau in je programma code het volgende plaatsen om je runtimeexceptions die toch niet voor kunnen komen op te vangen:

code:

catch(Exception e)
{
   JOptionPane.showMessageDialog(
     null, "Gefeliciteerd, je hebt de boel dus toch/n"
       + "dusdanig kunnen vernagelen dat het niet/n"
       + "meer te herstellen is./nAl je werk wordt/n"
       + "niet, ik herhaal, niet opgeslagen./n/n"
       + "Fijne dag verder.",
     "Je doet me versteld staan.",
     JOptionPane.INFORMATION_MESSAGE);

   System.Exit(0);
}

Lachen als het iemand dan toch een keer lukt om dat venstertje te zien...

Ik heb er weer een mooi scherm bij

code:

catch(Exception e)
{
   JOptionPane.showMessageDialog(
     null,"Inferior user error",
     "",
     JOptionPane.INFORMATION_MESSAGE);
   System.Exit(0);
}

of deze

code:

catch(Exception e)
{
   JOptionPane.showMessageDialog(
     null,"DE COMPUTER MOET NU UIT!!!!!!!!",
     "",
     JOptionPane.INFORMATION_MESSAGE);
   System.Exit(0);
}

ben weer veel te melig