Geketende uitzonderingen in Java

1. Overzicht

In dit artikel zullen we heel kort bekijken wat Uitzondering is en gaat dieper in op het bespreken van de gekoppelde uitzonderingen in Java.

Simpel gezegd, een uitzondering is een gebeurtenis die de normale stroom van de programma-uitvoering verstoort. Laten we nu precies zien hoe we uitzonderingen kunnen koppelen om er een betere semantiek uit te halen.

2. Geketende uitzonderingen

Geketend Uitzondering helpt om een situatie te identificeren waarin de ene uitzondering de andere veroorzaakt Uitzondering in een applicatie.

Overweeg bijvoorbeeld een methode die een ArithmeticException vanwege een poging om te delen door nul, maar de werkelijke oorzaak van de uitzondering was een I / O-fout waardoor de deler nul werd. ArithmeticException aan de beller. De beller zou niet weten wat de werkelijke oorzaak van een Uitzondering. Geketend Uitzondering wordt in dergelijke situaties gebruikt.

Dit concept is geïntroduceerd in JDK 1.4.

Laten we eens kijken hoe gekoppelde uitzonderingen worden ondersteund in Java.

**3. Gooibaar Klasse**

Gooibaar class heeft een aantal constructors en methoden om gekoppelde uitzonderingen te ondersteunen. Laten we eerst eens kijken naar de constructeurs.

Throwable (Throwable oorzaak) –Gooibaar heeft een enkele parameter, die de werkelijke oorzaak van een Uitzondering.
Throwable (String desc, Throwable oorzaak) – deze constructor accepteert een Uitzondering beschrijving met de werkelijke oorzaak van een Uitzondering ook.

Laten we vervolgens eens kijken naar de methoden die deze klasse biedt:

getCause () methode - Deze methode retourneert de werkelijke oorzaak die is gekoppeld aan de stroom Uitzondering.
initCause () methode - Het stelt een onderliggende oorzaak vast met een beroep Uitzondering.

4. Voorbeeld

Laten we nu eens kijken naar het voorbeeld waarin we ons eigen voorbeeld zullen stellen Uitzondering beschrijving en gooi een geketend Uitzondering:

openbare klasse MyChainedException {public void main (String [] args) {probeer {throw new ArithmeticException ("Top Level Exception.") .initCause (nieuwe IOException ("IO cause.")); } catch (ArithmeticException ae) {System.out.println ("Gevangen:" + ae); System.out.println ("Werkelijke oorzaak:" + ae.getCause ()); }}}

Zoals geraden zal dit leiden tot:

Gevangen: java.lang.ArithmeticException: uitzondering op het hoogste niveau. Werkelijke oorzaak: java.io.IO Uitzondering: IO-oorzaak.

5. Waarom gekoppelde uitzonderingen?

We moeten de uitzonderingen aan elkaar koppelen om logboeken leesbaar te maken. Laten we twee voorbeelden schrijven. Ten eerste zonder de uitzonderingen aan elkaar te koppelen en ten tweede met gekoppelde uitzonderingen. Later zullen we vergelijken hoe logboeken zich in beide gevallen gedragen.

Om te beginnen maken we een reeks uitzonderingen:

klasse NoLeaveGrantedException breidt Exception uit {public NoLeaveGrantedException (String-bericht, Throwable oorzaak) {super (bericht, oorzaak); } public NoLeaveGrantedException (String bericht) {super (bericht); }} class TeamLeadUpsetException breidt uitzondering uit {// Beide constructeurs}

Laten we nu de bovenstaande uitzonderingen gaan gebruiken in codevoorbeelden.

5.1. Zonder ketting

Laten we een voorbeeldprogramma schrijven zonder onze aangepaste uitzonderingen aan elkaar te koppelen.

openbare klasse MainClass {openbare leegte hoofd (String [] args) gooit Uitzondering {getLeave (); } void getLeave () gooit NoLeaveGrantedException {probeer {howIsTeamLead (); } catch (TeamLeadUpsetException e) {e.printStackTrace (); gooi nieuwe NoLeaveGrantedException ("Laat niet gesanctioneerd."); }} void howIsTeamLead () gooit TeamLeadUpsetException {gooi nieuwe TeamLeadUpsetException ("Team Lead Upset"); }}

In het bovenstaande voorbeeld zien logboeken er als volgt uit:

com.baeldung.chainedexception.exceptions.TeamLeadUpsetException: Teamleider Boos bij com.baeldung.chainedexception.exceptions.MainClass .howIsTeamLead (MainClass.java:46) op com.baeldung.chainedexception.exceptions.MainClass .getLeave (MainClass.java:34 ) op com.baeldung.chainedexception.exceptions.MainClass .main (MainClass.java:29) Uitzondering in thread "main" com.baeldung.chainedexception.exceptions. NoLeaveGrantedException: laat niet gesanctioneerd. op com.baeldung.chainedexception.exceptions.MainClass .getLeave (MainClass.java:37) bij com.baeldung.chainedexception.exceptions.MainClass .main (MainClass.java:29)

5.2. Met Chaining

Laten we vervolgens een voorbeeld schrijven met het koppelen van onze aangepaste uitzonderingen:

openbare klasse MainClass {openbare leegte hoofd (String [] args) gooit Uitzondering {getLeave (); } public getLeave () gooit NoLeaveGrantedException {probeer {howIsTeamLead (); } catch (TeamLeadUpsetException e) {throw new NoLeaveGrantedException ("Laat niet gesanctioneerd.", e); }} public void howIsTeamLead () gooit TeamLeadUpsetException {gooi nieuwe TeamLeadUpsetException ("Teamleider overstuur."); }}

Laten we tot slot eens kijken naar de logboeken die zijn verkregen met gekoppelde uitzonderingen:

Uitzondering in thread "main" com.baeldung.chainedexception.exceptions .NoLeaveGrantedException: Laat niet gesanctioneerd. bij com.baeldung.chainedexception.exceptions.MainClass .getLeave (MainClass.java:36) bij com.baeldung.chainedexception.exceptions.MainClass .main (MainClass.java:29) Veroorzaakt door: com.baeldung.chainedexception.exceptions .TeamLeadUpsetException : Teamleider Boos. op com.baeldung.chainedexception.exceptions.MainClass .howIsTeamLead (MainClass.java:44) bij com.baeldung.chainedexception.exceptions.MainClass .getLeave (MainClass.java:34) ... 1 meer

We kunnen de weergegeven logs eenvoudig vergelijken en concluderen dat de gekoppelde uitzonderingen tot schonere logs leiden.

In dit artikel hebben we het concept van geketende uitzonderingen bekeken.

De implementatie van alle voorbeelden is te vinden in het Github-project - dit is een op Maven gebaseerd project, dus het moet gemakkelijk te importeren en uit te voeren zijn zoals het is.

streamalism.org