Indpakning af en undtagelse

3. Indpakningsundtagelser

Tjekkede undtagelser virkede cool i teorien, men viste sig at være en kæmpe frustration i praksis.

Antag, at du har en super populær metode i dit projekt. Det kaldes fra hundredvis af steder i dit program. Og du beslutter dig for at tilføje en ny markeret undtagelse til den. Og det kan godt være, at denne afkrydsede undtagelse er rigtig vigtig og så speciel, at kun main()metoden ved, hvad den skal gøre, hvis den bliver fanget.

Det betyder , at du bliver nødt til at tilføje den markerede undtagelse til throwsklausulen for hver metode, der kalder din superpopulære metode . Samt i throwsklausulen af ​​alle de metoder, der kalder disse metoder. Og af de metoder, der kalder de metoder.

Som følge heraf throwsfår klausulerne i halvdelen af ​​metoderne i projektet en ny kontrolleret undtagelse. Og selvfølgelig er dit projekt dækket af test, og nu kompilerer testene ikke. Og nu skal du også redigere kast-klausulerne i dine tests.

Og så skal al din kode (alle ændringerne i hundredvis af filer) gennemgås af andre programmører. Og på dette tidspunkt spørger vi os selv, hvorfor vi lavede så mange blodige ændringer i projektet? Arbejdsdag(e?) og brudte tests - alt sammen for at tilføje en kontrolleret undtagelse?

Og selvfølgelig er der stadig problemer i forbindelse med arv og metodetilsidesættelse. Problemerne, der kommer fra kontrollerede undtagelser, er meget større end fordelen. Den nederste linje er, at nu er de færreste, der elsker dem, og få mennesker bruger dem.

Der er dog stadig meget kode (inklusive standard Java-bibliotekskode), der indeholder disse afkrydsede undtagelser. Hvad skal der gøres med dem? Vi kan ikke ignorere dem, og vi ved ikke, hvordan vi skal håndtere dem.

Java-programmører foreslog at indpakke kontrollerede undtagelser i RuntimeException. Med andre ord, fange alle de afkrydsede undtagelser og derefter oprette umarkerede undtagelser (for eksempel RuntimeException) og smid dem i stedet for. At gøre det ser sådan her ud:

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

Det er ikke en særlig køn løsning, men der er ikke noget kriminelt her: undtagelsen var simpelthen proppet inde i en RuntimeException.

Hvis det ønskes, kan du nemt hente det derfra. Eksempel:

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
   }
}