Forståelse af NumberFormatException i Java

1. Introduktion

Java kaster NumberFormatException - en ukontrolleret undtagelse - når den ikke kan konvertere en Snor til en nummertype.

Da det ikke er markeret, tvinger Java os ikke til at håndtere eller erklære det.

I denne hurtige vejledning beskriver vi og demonstrerer hvad der forårsager NumberFormatException i Java og hvordan man undgår eller håndterer det.

2. Årsager til NumberFormatException

Der er forskellige problemer, der forårsager NumberFormatException. For eksempel kaster nogle konstruktører og metoder i Java denne undtagelse.

Vi diskuterer de fleste af dem i nedenstående afsnit.

2.1. Ikke-numeriske data videregivet til konstruktøren

Lad os se på et forsøg på at konstruere en Heltal eller Dobbelt objekt med ikke-numeriske data.

Begge disse udsagn vil kaste NumberFormatException:

Heltal aHeltalObj = nyt heltal ("en"); Dobbelt doubleDecimalObj = ny Double ("two.2");

Lad os se stakksporingen, vi fik, da vi sendte ugyldig input "en" til Heltal konstruktør i linje 1:

Undtagelse i tråd "main" java.lang.NumberFormatException: For inputstreng: "one" på java.lang.NumberFormatException.forInputString (NumberFormatException.java:65) ved java.lang.Integer.parseInt (Integer.java:580) ved java.lang.Integer. (Integer.java:867) på MainClass.main (MainClass.java:11)

Det kastede NumberFormatException. Det Heltal konstruktøren mislykkedes under forsøget på at forstå input ved hjælp af parseInt () internt.

Java Number API analyserer ikke ord i tal, så vi kan rette koden ved blot at ændre den til en forventet værdi:

Heltal aHeltalObj = nyt heltal ("1"); Double doubleDecimalObj = new Double ("2.2");

2.2. Parsing af strenge, der indeholder ikke-numeriske data

I lighed med Java's support til parsing i konstruktøren har vi dedikerede analyseringsmetoder som parseInt (), parseDouble (), Værdi af()og afkode ().

Hvis vi prøver at udføre de samme former for konvertering med disse:

int aIntPrim = Integer.parseInt ("to"); dobbelt aDoublePrim = Double.parseDouble ("two.two"); Heltal aIntObj = Heltal.værdiOf ("tre"); Long decodedLong = Long.decode ("64403L");

Så ser vi den samme slags fejlagtige opførsel.

Og vi kan rette dem på lignende måder:

int aIntPrim = Integer.parseInt ("2"); dobbelt aDoublePrim = Double.parseDouble ("2.2"); Heltal aIntObj = Heltal.værdiOf ("3"); Long decodedLong = Long.decode ("64403");

2.3. Videregive strenge med fremmede tegn

Eller hvis vi prøver at konvertere en streng til et tal med fremmede data i input, som mellemrum eller specialtegn:

Short shortInt = new Short ("2"); int bIntPrim = Integer.parseInt ("_ 6000");

Derefter får vi det samme problem som før.

Vi kunne rette disse med lidt strengmanipulation:

Short shortInt = new Short ("2" .trim ()); int bIntPrim = Integer.parseInt ("_ 6000" .replaceAll ("_", "")); int bIntPrim = Integer.parseInt ("- 6000");

Bemærk her i linje 3, at negative tal er tilladt, der bruger bindestregtegnet som et minustegn.

2.4. Lokalspecifikke talformater

Lad os se et specielt tilfælde af landespecifikke tal. I europæiske regioner kan et komma repræsentere en decimal. For eksempel kan "4000,1" repræsentere decimaltallet "4000,1".

Som standard får vi det NumberFormatException ved at prøve at analysere en værdi, der indeholder et komma:

dobbelt aDoublePrim = Double.parseDouble ("4000,1");

Vi er nødt til at tillade kommaer og undgå undtagelsen i dette tilfælde. For at gøre dette muligt skal Java forstå kommaet her som en decimal.

Vi kan tillade kommaer for den europæiske region og undgå undtagelsen ved at bruge NumberFormat.

Lad os se det i aktion ved hjælp af Lokal for Frankrig som et eksempel:

NumberFormat numberFormat = NumberFormat.getInstance (Locale.FRANCE); Number parsedNumber = numberFormat.parse ("4000,1"); assertEquals (4000.1, parsedNumber.doubleValue ()); assertEquals (4000, parsedNumber.intValue ()); 

3. Bedste praksis

Lad os tale om et par gode fremgangsmåder, der kan hjælpe os med at håndtere NumberFormatException:

  1. Forsøg ikke at konvertere alfabetiske eller specialtegn til tal - Java Number API kan ikke gøre det.
  2. Det vil vi måske valider en inputstreng ved hjælp af regulære udtryk og kast undtagelsen for de ugyldige tegn.
  3. Vi kan desinficere input mod forudsigelige kendte problemer med metoder som trimme() og erstatteAlle ().
  4. I nogle tilfælde kan specialtegn i input være gyldige. Så vi laver speciel behandling for det ved hjælp af Nummerformat, for eksempel, som understøtter adskillige formater.

4. Konklusion

I denne vejledning diskuterede vi NumberFormatException i Java og hvad der forårsager det. At forstå denne undtagelse kan hjælpe os med at skabe mere robuste applikationer.

Desuden lærte vi strategier for at undgå undtagelsen med nogle ugyldige inputstrenge.

Endelig så vi et par bedste fremgangsmåder til håndtering NumberFormatException.

Som normalt kan kildekoden, der bruges i eksemplerne, findes på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found