Undantagshierarki, fel

"Hej, Amigo!"

"Hej, Ellie! Hur är livet?"

"Utmärkt, tack. Hur mår du?"

"Jättebra, i morse förklarades massor av nya saker för mig."

"Tja, det är bra. Du är inte trött?"

"Ja, det finns det. Jag är lite trött."

"Då hade du bara tur. Jag ville ta upp ett stort, komplext ämne idag, men i sista minuten ändrade jag mig och bestämde mig för att ta upp ett litet, enkelt."

"Liten och lätt? Jag är redo."

"Idag kommer vi att undersöka ämnet undantag i detalj."

"Pratar du om felhantering?"

"Du ska inte tänka på undantag som fel. Undantag är mer som rapporter om att "något oväntat hänt". Baserat på dessa rapporter kan du föreslå alternativa åtgärder."

"Allt handlar om metoder.  När du kallar en metod, lovar den att göra vad den kallades att göra. "

"När en metod, av någon anledning, inte kan göra vad den kallades att göra, måste den meddela den som ringer."

"Med andra ord, det värsta som kan hända är att en metod inte gör sitt arbete och inte berättar för någon om det. Ingenting kan vara värre än så. Du tappar kontrollen över situationen när det händer. "

"När du är en ny programmerare verkar det som att du bara ringer metoder och de är säker på att göra det du bad dem att göra."

"När du är en erfaren programmerare vet du att det kan finnas dussintals faktorer som påverkar en metods förmåga att göra sitt jobb, och att det finns många fall som kan hindra en metod från att slutföra sitt jobb."

"Från programmerarens perspektiv är det tusen gånger bättre om ett program avslutas när det stöter på ett fel än om programmet stöter på ett fel och sedan fortsätter att fungera (felaktigt) utan att användaren inser vad som hände."

"Så programmet som visar något fel kan vara värre än om programmet stängdes och förlorade all data?"

"Vad fick dig att tro att programmet helt enkelt visar något felaktigt? Kanske programmet har massor av buggar och all din data kommer att gå oåterkalleligt förlorad? Anta att du har skrivit in text i 3 timmar, men inget av det kommer att sparas eftersom en fel som uppstod efter bara två minuter."

"När en nybörjare stöter på undantag blir han frustrerad."

"Men i verkligheten avslöjar undantag alla möjliga scenarier som han borde ha förutsett men inte gjorde."

"Du kan välja att inte hantera undantag och det skulle göra dig till en dålig programmerare. Men om dina metoder inte ger undantag, då är du ingen programmerare alls - eftersom du misslyckades med att förstå denna enkla sanning:"

"en metod gör antingen vad den skrevs för att göra, eller så skapar den ett undantag. Det finns inget tredje alternativ!"

"Okej, jag tror dig. Jag lovar att använda undantag."

"Bra. Låt mig då berätta om hierarkin av undantag:"

"Undantagshierarkin är baserad på fyra klasser."

"Den lägsta basklassen är Throwable ."

" Fel- och undantagsklasserna ärver det."

" RuntimeException ärver Exception ."

" Klassen Error är basklassen för JVM-fel som StackOverFlow , OutOfMemory , ..."

"Ett program kan vanligtvis inte återhämta sig från sådana fel, vilket leder till att det avslutas."

"Faktiskt, vad kan man göra om det inte finns tillräckligt med minne för att programmet ska fortsätta köra normalt eller om det har skett ett stackspill?"

" Exception är basklassen för alla vanliga undantag som skapas av ett program.  RuntimeException är en speciell typ av undantag som har lite olika regler."

"Vad är dem?"

"Det är precis vad jag ska förklara nu."

"Som du säkert kommer ihåg faller undantag i två kategorier: markerade och omarkerade ."

"Om en metod kastar kontrollerade undantag, måste metoden som anropar den linda anropet i ett försök-fångst- block. Tja, antingen det eller kasta om undantaget (till dess anropare) genom att tydligt indikera kast i metodsignaturen."

"Dessa regler/begränsningar gäller inte för omarkerade undantag."

"Så, alla undantag som ärver Exception anses vara kontrollerade. Förutom undantag som ärver RuntimeException, som anses vara omarkerade."

"Äh-ha. Jag minns att du berättade något sådant för mig tidigare."

"Amigo! De frågar om undantagshierarkin i varje intervju . Jag säger det igen - varje intervju . Du måste känna till detta ämne perfekt."

"OK. Jag ska läsa allt igen och ta reda på det. Tack för att du hjälper mig, Ellie."