Programmering Java: Kaste fejl - dummies

Det er vigtigt, at din Java kode gør alt for at løse et problem. Der er dog tidspunkter, hvor din kode simpelthen ikke har tilstrækkelig information, ressourcer, rettigheder eller noget andet krav til at løse et problem.

Når dette sker, kaster din kode en fejl ved at bruge en undtagelsesobjekt. Udtrykket undtagelse er passende, fordi det burde være undtagelsen fra reglen, snarere end den første handling, som applikationen udfører. Alligevel er der fejl i applikationer, der kræver ekstraordinære foranstaltninger, og de følgende afsnit beskriver, hvordan man håndterer disse slags situationer.

Kaste fejl under ekstraordinære forhold

Til praksis kan du oprette et program, der kan generere flere typer fejl. Normalt vil du ikke smide en fejl, hvis en værdi er i det forkerte område - du vil vise en besked direkte til brugeren i stedet. Du kan dog oprette et eksempel, der viser, hvordan man smider og fanger en fejl fra en metode.

Passeringsfejl til opkalderen

Mange kodeeksempler, du begynder med, er lige begyndt at komme til det punkt, hvor du ringer metoder fra main (). Hovedmetoden () er altid det øverste niveau af din ansøgning. Som du kalder metoder, de metoder, du ringer til, danner flere niveauer.

For eksempel vil en metode, der hedder fra main (), være på det andet niveau af din ansøgning. Hvis den metode skulle kalde en anden metode, ville den metode være på tredje niveau og så videre. De fleste applikationer består af mange niveauer af opkald.

Når du ser en undtagelse på skærmen, vises det faktisk en liste over de metoder, der kaldte den aktuelle metode i et format kaldet call stack.

Opkaldsstakken er en liste over metoder og rækkefølgen, hvor de kaldes af andre metoder. At kende opkaldsstakken kan hjælpe dig med at finde kilden til en potentiel fejl, når det ikke sker på det nuværende niveau af applikationen.

Håndteringsfejl er en vigtig del af god programmeringspraksis. Hvis du vil have robuste applikationer, der ikke konstant styrter, skal du sørge for god fejlhåndtering. Men det er også et problem at forsøge at håndtere en fejl, når du ikke har nok information til at håndtere denne fejl.

Når din kode forsøger at rette en fejl på for lavt niveau, gemmer den fejlen fra et niveau, der muligvis kan rette det. Ja, du vil rette en fejl på det lavest mulige niveau, men ikke på bekostning af at yde en reparation, der rent faktisk kan ende med at gemme noget mere alvorligt.

Når du finder ud af, at et bestemt niveau af en applikation ikke har de nødvendige ressourcer, oplysninger, privilegier, brugeradgang eller noget andet element, der er nødvendigt for at håndtere en fejl, udsteder du en kasteopgørelse med den relevante undtagelsesobjekt.Det foregående niveau af ansøgningen vil modtage undtagelsen og afgøre, om den kan klare det.

Men hvis metoden main () modtager undtagelsen, skal du bestemme, hvad du skal gøre med fejlen, eller applikationen vil gå ned. Det er generelt betragtes som dårlig programmeringspraksis for at lade applikationen gå i stykker - du skal komme på en eller anden måde til at håndtere fejl, som applikationen møder.

Nødvendig fejlhåndtering

Java indeholder to slags undtagelser: kontrolleret (de overvågede af JRE) og ukontrollerede (de, der ikke overvåges af JRE). Du har mulighed for at håndtere en ukontrolleret undtagelse. Men Java tvinger dig til at håndtere en markeret undtagelse. Din kode kompilerer ikke engang, hvis du forsøger at bruge en metode, der har en markeret undtagelse, der er forbundet med den.

En kontrolleret undtagelse er en, som JRE bliver fortalt af klassen definition at overvåge. JRE tvinger brugeren af ​​klassen til at give håndtering til undtagelsen for at sikre, at klassen udfører pålideligt.

Alle former for ulige detaljer er forbundet med kontrollerede og ukontrollerede undtagelser. En nem måde at vide om en undtagelse er markeret er at kende forældrenes klasse. Alle undtagelser, der er underklassificeret fra klasserne Error eller RuntimeException, er ikke markeret - alle andre undtagelser er markeret.

Den bedste praksis er at håndtere enhver undtagelse i din ansøgning, og du behøver ikke bekymre dig om, hvorvidt en undtagelse er markeret eller ikke markeret. En stor udvikler håndterer altid mulige fejl - det er bundlinjen.