Voordelen van uitzonderingen in Java programmeertaal

Share

|

Een uitzondering is een evenement, dat plaatsvindt tijdens de uitvoering van een programma, dat de normale stroom van de instructies van het programma verstoort.

Voordeel 1: Scheiden Error-handling code van "Reguliere" Code

Uitzonderingen worden voorzien in middelen om de details van wat te doen als er iets bijzonders gebeurt van de belangrijkste logica van een programma te scheiden. In de traditionele programmering, foutdetectie, rapportage en behandeling leiden vaak tot verwarrende spaghetti code. Denk bijvoorbeeld aan de pseudocode methode hier dat een hele bestand in het geheugen luidt als volgt:

ReadFile (
Open het bestand;
zijn bepalend voor de grootte;
toewijzen dat veel geheugen;
Lees het bestand in het geheugen;
Sluit het bestand;
)

Op het eerste gezicht lijkt deze functie eenvoudig genoeg, maar het gaat voorbij aan de volgende potentiële fouten:

• Wat gebeurt er als het bestand niet kan worden geopend?

• Wat gebeurt er als de lengte van het bestand niet kan worden bepaald?

• Wat gebeurt er als er voldoende geheugen niet kan worden toegewezen?

• Wat gebeurt er als het lezen mislukt?

• Wat gebeurt er als het bestand niet kan worden gesloten?

Behandeling van dergelijke zaken, moet de ReadFile functie meer code foutdetectie doen, rapportage en behandeling. Hier is een voorbeeld van wat de functie zou kunnen zien:

errorCodeType ReadFile (
initialiseren errorCode = 0;

Open het bestand;
if (theFileIsOpen) (
bepaalt de duur van het bestand;
if (gotTheFileLength) (
toewijzen dat veel geheugen;
if (gotEnoughMemory) (
Lees het bestand in het geheugen;
if (readFailed) (
errorCode = -1;
)
) Else (
errorCode = -2;
)
) Else (
errorCode = -3;
)
Sluit het bestand;
if (theFileDidntClose & & errorCode == 0) (
errorCode = -4;
) Else (
errorCode = errorCode en -4;
)
) Else (
errorCode = -5;
)
return errorCode;
)

Er is zoveel foutdetectie, rapportage, en terug hier dat de oorspronkelijke zeven lijnen van de code zijn verloren in de rommel. Erger nog, is de logische stroom van de code ook verloren is gegaan, waardoor het moeilijk te zeggen of de code het juiste ding doet: Is het bestand werkelijk wordt gesloten als de functie niet voldoende geheugen toewijzen? Het is nog moeilijker om ervoor te zorgen dat de code nog steeds het juiste ding wanneer u de methode te wijzigen drie maanden na het schrijven van het te doen. Veel programmeurs dit probleem oplossen door simpelweg te negeren iterrors worden gerapporteerd wanneer hun programma's crashen.

Uitzonderingen kunt u de belangrijkste stroom van je code te schrijven en om te gaan met de uitzonderlijke gevallen elders. Als de functie ReadFile uitzonderingen in plaats van de traditionele fout-management technieken gebruikt, zou het lijken meer op de volgende:

ReadFile (
try (
Open het bestand;
zijn bepalend voor de grootte;
toewijzen dat veel geheugen;
Lees het bestand in het geheugen;
Sluit het bestand;
) Catch (fileOpenFailed) (
doSomething;
) Catch (sizeDeterminationFailed) (
doSomething;
) Catch (memoryAllocationFailed) (
doSomething;
) Catch (readFailed) (
doSomething;
) Catch (fileCloseFailed) (
doSomething;
)
)

Merk op dat uitzonderingen geen reserveonderdelen u de moeite van het doen van het werk van het opsporen, rapportage en het afhandelen van fouten, maar ze helpen je organisatie van de werkzaamheden efficiënter te maken.

Voordeel 2: Propagating Fouten Tot de Call Stack

Een tweede voordeel van de uitzonderingen is de mogelijkheid om foutrapportage het gesprek stapel van methoden propageren. Stel dat de ReadFile methode methode is het vierde in een reeks van geneste methode oproepen van de belangrijkste programma: method1 oproepen method2, die method3 gesprekken, die uiteindelijk oproepen ReadFile:

method1 (
oproep method2;
)

method2 (
oproep method3;
)

method3 (
oproep ReadFile;
)

Stel ook dat method1 is de enige methode geïnteresseerd in de fouten die kunnen optreden binnen ReadFile. traditionele fout-melding technieken kracht method2 en method3 de foutcodes geretourneerd door ReadFile het gesprek stapel propageren totdat de foutcodes eindelijk method1the enige methode die geïnteresseerd is in hen te bereiken:

method1 (
errorCodeType fout;
fout = oproep method2;
if (fout)
doErrorProcessing;
anders
doorgaan;
)

errorCodeType method2 (
errorCodeType fout;
fout = oproep method3;
if (fout)
return fout;
anders
doorgaan;
)

errorCodeType method3 (
errorCodeType fout;
fout = oproep ReadFile;
if (fout)
return fout;
anders
doorgaan;
)

Bedenk dat de Java runtime environment zoekt achteruit door de call stack op alle methoden die geïnteresseerd zijn in het omgaan met een bepaalde uitzondering vinden. Een methode kan eend eventuele uitzonderingen gegooid daarbinnen, waardoor een methode verder het gesprek stapel te vangen. Vandaar dat alleen de methoden die zorg over fouten zorgen te maken over het opsporen van fouten:

method1 (
try (
oproep method2;
) Catch (Exception e) (
doErrorProcessing;
)
)

method2 gooit uitzondering (
oproep method3;
)

method3 gooit uitzondering (
oproep ReadFile;
)

Echter, zoals de pseudocode blijkt, ducking een uitzondering vergt enige inspanning van de kant van de tussenpersoon methoden. Eventuele uitzonderingen die gecontroleerd kunnen worden gegooid binnen een methode moet worden gespecificeerd in haar gooit clausule.

Voordeel 3: Groepering en differentiëren Fout Types

Omdat alle uitzonderingen gegooid binnen een programma zijn objecten, de groepering of categoriseren van uitzonderingen is een natuurlijk gevolg van de klasse hiërarchie. Een voorbeeld van een groep van verwante uitzondering klassen in de Java-platform staan omschreven in java.ioIOException en haar nakomelingen. IOException is de meest algemene en vertegenwoordigt een type fout die kan optreden bij het uitvoeren van I / O. Zijn nakomelingen vertegenwoordigen meer specifieke fouten. Bijvoorbeeld FileNotFoundException betekent dat een bestand niet kon worden gevestigd op de schijf.

Een methode kan schrijven specifieke handlers die overweg kan met een zeer specifieke uitzondering. De FileNotFoundException klasse heeft geen nakomelingen, zodat de volgende handler kan verwerken slechts een type uitzondering:

catch (FileNotFoundException e) (
...
)

Een methode kan vangen een uitzondering op basis van haar groep of algemene type door vermelding van een van superklassen de uitzondering in de catch-statement. Bijvoorbeeld te vangen alle I / O uitzonderingen, ongeacht hun specifieke soort, een uitzondering handler specificeert een IOException argument:

catch (IOException e) (
...
)

Deze handler staat zullen zijn om alle I / O uitzonderingen, waaronder FileNotFoundException, EOFException, enzovoort vangen. U kunt informatie vinden over wat er gebeurde door bevragen het argument doorgegeven aan de uitzondering handler. Gebruik bijvoorbeeld de volgende af te drukken de stack trace:

catch (IOException e) (
e.printStackTrace (); / / Output gaat naar System.err.
e.printStackTrace (instructie System) / / Stuur spoor naar stdout.
)

Je zou zelfs het opzetten van een uitzondering handler die iedere uitzondering met de geleider hier grepen:

catch (Exception e) (/ / A (te) algemene uitzondering handler
...
)

De Exception klasse ligt dicht bij de top van de THRowable klasse hiërarchie. Daarom zal deze handler vangen veel andere uitzonderingen in naast de beperkingen die de handler is bedoeld om te vangen. Misschien wilt u uitzonderingen op deze manier behandelen als al je programma te doen, bijvoorbeeld wilt afdrukken is een foutmelding voor de gebruiker en vervolgens af te sluiten.

In de meeste situaties echter, wil je uitzondering handlers zo specifiek mogelijk te zijn. De reden is dat het eerste wat een handler moet doen is bepalen welk type van uitzondering opgetreden voordat het kan beslissen over de beste strategie voor herstel. In feite, door niet vangen specifieke fouten, moet de geleider geschikt voor elke mogelijkheid. Uitzondering handlers die te algemeen zijn kan code meer foutgevoelig te maken door het vangen en hanteren van uitzonderingen die niet werden verwacht door de programmeur en waarvoor de handler niet was bedoeld.

Zoals vermeld, kunt u groepen van uitzonderingen en afwijkingen verwerken in een algemene manier, of u kunt gebruik maken van de specifieke uitzondering soort uitzonderingen te differentiëren en uitzonderingen op een exacte manier te behandelen.

---