Een uitzondering inpakken

3. Verpakkingsuitzonderingen

Gecontroleerde uitzonderingen leken in theorie cool, maar bleken in de praktijk een enorme frustratie.

Stel dat je een super populaire methode in je project hebt. Het wordt aangeroepen vanuit honderden plaatsen in uw programma. En u besluit er een nieuwe aangevinkte uitzondering aan toe te voegen. En het kan heel goed zijn dat deze aangevinkte exception echt belangrijk is en zo bijzonder dat alleen de main()methode weet wat te doen als hij wordt betrapt.

Dat betekent dat je de aangevinkte uitzondering moet toevoegen aan de clausule van elke methode die je super populaire methode aanroeptthrows . Evenals in de throwsclausule van alle methoden die deze methoden aanroepen. En van de methodes die die methodes aanroepen.

Als gevolg hiervan throwskrijgen de clausules van de helft van de methoden in het project een nieuwe aangevinkte uitzondering. En natuurlijk wordt uw project gedekt door tests, en nu worden de tests niet gecompileerd. En nu moet je ook de throws-clausules in je tests bewerken.

En dan moet al je code (alle wijzigingen in honderden bestanden) door andere programmeurs worden beoordeeld. En op dit punt vragen we ons af waarom we zoveel verdomde veranderingen in het project hebben aangebracht? Dag(en?) werk en mislukte tests - allemaal om één aangevinkte uitzondering toe te voegen?

En natuurlijk zijn er nog steeds problemen met overerving en methodeoverheersing. De problemen die voortkomen uit gecontroleerde uitzonderingen zijn veel groter dan het voordeel. Het komt erop neer dat nu maar weinig mensen van ze houden en dat maar weinig mensen ze gebruiken.

Er is echter nog steeds veel code (inclusief standaard Java-bibliotheekcode) die deze gecontroleerde uitzonderingen bevat. Wat moet er met hen gebeuren? We kunnen ze niet negeren en we weten niet hoe we ze moeten aanpakken.

Java-programmeurs stelden voor om aangevinkte uitzonderingen in RuntimeException. Met andere woorden, vang alle aangevinkte uitzonderingen op en maak vervolgens ongecontroleerde uitzonderingen (bijvoorbeeld RuntimeException) en gooi ze in plaats daarvan weg. Dat doen ziet er ongeveer zo uit:

try
{
   // Code where a checked exception might occur
}
catch(Exception exp)
{
   throw new RuntimeException(exp);
}

Het is geen erg mooie oplossing, maar er is niets crimineels aan: de uitzondering zat gewoon in een RuntimeException.

Desgewenst kunt u deze daar eenvoudig weer ophalen. Voorbeeld:

try
{
   // Code where we wrap the checked exception
   // in a RuntimeException
}
catch(RuntimeException e)
{
   Throwable cause = e.getCause();
   if (cause instanceof Exception)
   {
      Exception exp = (Exception) cause;
      // Exception handling code goes here
   }
}