Konwersja łańcucha na liczby całkowite w bezpieczny sposób

Question

Mam małą metodę, która między innymi konwertuje ciąg na liczbę całkowitą. Ponieważ ciąg jest parametrem metody, chcę się upewnić, że ten ciąg jest konwertowalny. Więc zastanawiałem się, jaki byłby najbezpieczniejszy i/lub najszybszy sposób.

---

Wersja A: Wystarczy zostawić tak jak jest i podjąć ryzyko (które staram się unikać)

public static int stringToInt(String param) { 
     return Integer.valueOf(param); 
} 

(pod względem szybkości, jaką za różnica to uczynić do wersji B i C)

---

Wersja B: Catch ex ception

public static int stringToInt(String param) { 
     try { 
       return Integer.valueOf(param); 
     } catch(NumberFormatException e) { 
       return -1; 
     } 
} 

---

Wersja C: Sprawdź każdą literę napisu, aby zobaczyć, czy jest to cyfra lub nie

public static int stringToInt(String param) { 
     for(char c : param.toCharArray()) { 
       if(!Character.isDigit(c)) 
         return -1; 
     } 
     return Integer.valueOf(param); 
} 

---

Należy zauważyć, że parametr musi być liczba dodatnia i -1 mają być "wartością błędu" w moim małym programie, innymi słowy, wszystkie trzy wersje metod działałyby idealnie w moim programie.

Jestem bardzo otwarty na wszelkie inne sugestie, które możesz mi podać, więc możesz utworzyć własną wersję, jeśli uważasz, że jest lepsza.

Dziękuję bardzo za wsparcie z góry.

Answer 1

Po pierwsze, należy pamiętać, że wersja C nie jest kuloodporna: odrzuciłaby liczby ujemne i nie przechwyciłaby zbyt dużych liczb.

Wersja B jest OK, ale powoduje, że osoba wywołująca zmienia styl kodowania: zamiast złapać błąd i przetworzyć go razem z innymi błędami, osoba dzwoniąca musi cały czas sprawdzać, czy nie ma ona wartości -1. Może to być nieoptymalne w sytuacjach, w których czytasz wiele liczb całkowitych, ale przetwarzanie błędów nie zależy od tego, który z nich się nie powiódł. Ponadto nowi koderowie korzystający z Twojego interfejsu API mogą zapomnieć o sprawdzeniu, czy kodowanie jest -1 i nieumyślnie użyć kodu błędu.

Dlatego pozostaję z pierwszą opcją: kod używający wersji A będzie od razu wyglądać znajomo dla każdego, kto zna API Java, bez potrzeby uczenia się, co dzieje się wewnątrz funkcji.

Answer 2

Wierzę, że zmodyfikowany B, aby rzucić wyjątek, a nie powrócić -1, będzie najlepszym wyborem. Dobrze jest rzucić wyjątek na poziom, na którym można go przetworzyć, aby wysłać właściwą odpowiedź użytkownikowi. Zwrócenie wartości takiej jak -1 spowoduje, że Twój kod będzie podatny na błędy. Załóżmy, że inny programista zużywa twoją metodę i ma po prostu podpis twojej metody. Z podpisu nie wynika więc, co kodować, aby obsłużyć scenariusz wyjątku lub błędu. Ale jeśli wyrzucisz wyjątek i dodasz go do deklaracji metody, to umożliwi to drugiemu programistowi prawidłowe wykorzystanie metody zgodnie z wymaganą obsługą wyjątku.Dla mnie to wygląda najlepiej:

public static int stringToInt(String param) throws NumberFormatException { 
     try { 
       return Integer.valueOf(param); 
     } catch(NumberFormatException e) { 
       // return -1; 
       throw e; 
     } 
} 

Answer 3

Guava oferuje metodę narzędzia, która zwraca null w przypadku, gdy Twój ciąg nie może zostać przeanalizowany.

https://google.github.io/guava/releases/19.0/api/docs/com/google/common/primitives/Ints.html#tryParse(java.lang.String)

Integer result = Ints.tryParse("1"); //returns 1 
Integer result = Ints.tryParse("-1"); //returns -1 
Integer result = Ints.tryParse("a"); //returns null