Ciąg do Int w java - Prawdopodobnie złe dane, należy unikać wyjątków

Question

Widząc, że Java nie ma typów zerujących, ani nie ma TryParse(), jak radzić sobie z sprawdzaniem danych wejściowych bez zgłaszania wyjątków?

Zwykłym sposobem:

String userdata = /*value from gui*/ 
int val; 
try 
{ 
    val = Integer.parseInt(userdata); 
} 
catch (NumberFormatException nfe) 
{ 
    // bad data - set to sentinel 
    val = Integer.MIN_VALUE; 
} 

mogę użyć wyrażenia regularnego, aby sprawdzić, czy to parsowalnym, ale to wydaje się dużo napowietrznych, jak również.

Jaka jest najlepsza praktyka w radzeniu sobie z tą sytuacją?

EDYCJA: Uzasadnienie: Dużo się mówi na temat obsługi wyjątków, a ogólna opinia jest taka, że ​​wyjątki powinny być używane tylko w przypadku nieoczekiwanych scenariuszy. Jednak uważam, że złe dane wejściowe użytkownika są OCZEKIWANE, a nie rzadkie. Tak, to naprawdę jest punkt akademicki.

Kolejne edycje:

Niektóre z odpowiedzi wykazać dokładnie to, co jest nie tak z SO. Ignorujesz pytanie, które zadajesz, i odpowiadasz na inne pytanie, które nie ma z tym nic wspólnego. Pytanie nie pyta o przejście między warstwami. Pytanie nie pyta, co zwrócić, jeśli liczba nie jest parsowana. Dla wszystkich, których znasz, val = Integer.MIN_VALUE; jest dokładnie odpowiednią opcją dla aplikacji, z której powstał ten całkowicie wolny od kontekstu fragment kodu.

Answer 1

To prawie wszystko, chociaż powrót do wartości MIN_VALUE jest wątpliwy, chyba że masz pewność, że używasz tego, co w zasadzie używasz jako kodu błędu. Ale przynajmniej udokumentowałem zachowanie kodu błędu.

Może być również przydatny (w zależności od aplikacji) do rejestrowania złych danych wejściowych, aby można było śledzić.

Answer 2

Umieść przed nim jakieś instrukcje if. if (null! = Userdata)

Answer 3

Uważam, że najlepszą praktyką jest kod, który pokazujesz.

Nie wybrałbym alternatywy dla regex ze względu na obciążenie.

Answer 4

Jaki jest problem z twoim podejściem? Nie sądzę, aby robienie tego w ten sposób wpłynęło na wydajność twojej aplikacji. To jest właściwy sposób, aby to zrobić. Nie optymalizuj przedwcześnie.

Answer 5

Jestem pewien, że jest to zła forma, ale mam zestaw metod statycznych w klasie narzędzi, które robią takie rzeczy jak Utilities.tryParseInt(String value) który zwraca 0 jeśli łańcuch jest unparseable i Utilities.tryParseInt(String value, int defaultValue) który pozwala określić wartość do użycia, jeśli parseInt() zgłasza wyjątek.

Wierzę, że zdarzają się sytuacje, w których zwracanie znanej wartości na błędnym wejściu jest całkowicie dopuszczalne. Bardzo wymyślny przykład: pytasz użytkownika o datę w formacie YYYYMMDD i daje ci złe dane wejściowe. W zależności od wymagań programu może być całkowicie dopuszczalne wykonanie czegoś takiego jak Utilities.tryParseInt(date, 19000101) lub Utilities.tryParseInt(date, 29991231);.

Answer 6

Możesz użyć liczby całkowitej, która może mieć wartość null, jeśli masz złą wartość. Jeśli używasz java 1.6, zapewni Ci automatyczne boksowanie/rozpakowywanie.

Answer 7

Powyższy kod jest nieprawidłowy, ponieważ jest równoważny poniższemu.

// this is bad 
int val = Integer.MIN_VALUE; 
try 
{ 
    val = Integer.parseInt(userdata); 
} 
catch (NumberFormatException ignoreException) { } 

Wyjątek jest całkowicie ignorowany. Ponadto magiczny token jest zły, ponieważ użytkownik może przejść w -2147483648 (Integer.MIN_VALUE).

Ogólne pytanie, które można przeanalizować, nie jest korzystne. Powinien raczej być odpowiedni do kontekstu. Twoja aplikacja ma określone wymagania. Można zdefiniować swoją metodę jako

private boolean isUserValueAcceptable(String userData) 
{ 
    return ( isNumber(userData)  
      && isInteger(userData) 
      && isBetween(userData, Integer.MIN_VALUE, Integer.MAX_VALUE) 
     ); 
} 

gdzie można dokumentacja wymóg i można stworzyć dobrze zdefiniowane i sprawdzalne zasad.

Answer 8

Dla danych dostarczanych przez użytkownika, Integer.parseInt jest zwykle złą metodą, ponieważ nie obsługuje internacjonalizacji. Pakiet java.text jest Twoim (gadatliwym) przyjacielem.

try { 
    NumberFormat format = NumberFormat.getIntegerInstance(locale); 
    format.setParseIntegerOnly(true); 
    format.setMaximumIntegerDigits(9); 
    ParsePosition pos = new ParsePosition(0); 
    int val = format.parse(str, pos).intValue(); 
    if (pos.getIndex() != str.length()) { 
     // ... handle case of extraneous characters after digits ... 
    } 
    // ... use val ... 
} catch (java.text.ParseFormatException exc) { 
    // ... handle this case appropriately ... 
} 

Answer 9

Oto jak to zrobić:

public Integer parseInt(String data) { 
    Integer val = null; 
    try { 
    val = Integer.parseInt(userdata); 
    } catch (NumberFormatException nfe) { } 
    return val; 
} 

Następnie sygnały zerowe nieprawidłowych danych. Jeśli chcesz mieć wartość domyślną, można go zmienić na:

public Integer parseInt(String data,int default) { 
    Integer val = default; 
    try { 
    val = Integer.parseInt(userdata); 
    } catch (NumberFormatException nfe) { } 
    return val; 
} 

Answer 10

Jeśli można uniknąć wyjątki testując wcześniej jak mówiłeś (isParsable()) może być lepiej - ale nie wszystkie biblioteki, które zostały zaprojektowane z na uwadze.

Kiedyś trick i to jest do bani bo ślady stos na moim wbudowanego systemu są drukowane niezależnie od tego, czy je złapać czy nie :(

Answer 11

Mechanizm Wyjątkiem jest cenne, ponieważ jest to jedyny sposób, aby uzyskać status Wskaźnik w połączeniu z wartością odpowiedzi Ponadto, wskaźnik statusu jest ustandaryzowany Jeśli wystąpi błąd, otrzymasz wyjątek, w ten sposób nie musisz samodzielnie wymieniać wskaźnika błędu Kontrowersje to nie tyle wyjątki , ale z zaznaczonymi wyjątkami (np. te, które musisz złapać lub zadeklarować)

Osobiście uważam, że wybrałeś jeden z przykładów, w których wyjątki są prawdziwe ly cenny. Jest to powszechny problem, w którym użytkownik wprowadza błędną wartość, i zazwyczaj trzeba będzie zwrócić się do użytkownika, aby uzyskać poprawną wartość. Zwykle nie powracasz do domyślnej wartości, jeśli zapytasz użytkownika; daje to użytkownikowi wrażenie, że jego wkład ma znaczenie.

Jeśli nie chcesz zajmować się wyjątkiem, po prostu zapakuj go w wyjątek RuntimeException (lub klasę pochodną), co pozwoli ci zignorować wyjątek w kodzie (i zabić aplikację, gdy wystąpi, to też jest w porządku czasami).

kilka przykładów, jak bym sobie wyjątki numberFormat: W internetowej danych konfiguracyjnych aplikacji:

loadCertainProperty(String propVal) { 
    try 
    { 
    val = Integer.parseInt(userdata); 
    return val; 
    } 
    catch (NumberFormatException nfe) 
    { // RuntimeException need not be declared 
    throw new RuntimeException("Property certainProperty in your configuration is expected to be " + 
           " an integer, but was '" + propVal + "'. Please correct your " + 
           "configuration and start again"); 
    // After starting an enterprise application the sysadmin should always check availability 
    // and can now correct the property value 
    } 
} 

W GUI:

public int askValue() { 
    // TODO add opt-out button; see Swing docs for standard dialog handling 
    boolean valueOk = false; 
    while(!valueOk) { 
    try { 
     String val = dialog("Please enter integer value for FOO"); 
     val = Integer.parseInt(userdata); 
     return val; 
    } catch (NumberFormatException nfe) { 
     // Ignoring this; I don't care how many typo's the customer makes 
    } 
    } 
} 

w formie internetowej: powrót formę użytkownikowi z przydatnym komunikatem o błędzie i szansą na poprawne poprawienie wartości . Większość frameworków oferuje znormalizowany sposób sprawdzania poprawności.

Answer 12

mam zamiar przekształcenia tego stopnia, że ​​stinkyminky robił w kierunku dolnej części postu:

ogólnie dobrze przyjęte podejście Weryfikacja danych użytkownika (lub wejście z plików konfiguracyjnych, etc ...) jest w użyciu sprawdzanie poprawności przed faktycznym przetwarzaniem danych. W przypadku większości przypadków jest to dobry ruch konstrukcyjny, nawet jeśli może powodować wiele wywołań algorytmów analizy.

Po sprawdzeniu poprawności danych wprowadzonych przez użytkownika: , następnie, można bezpiecznie je przeanalizować i zignorować, zarejestrować lub przekonwertować na RuntimeException wyjątek NumberFormatException.

Należy zauważyć, że to podejście wymaga uwzględnienia modelu w dwóch elementach: modelu biznesowego (gdzie naprawdę zależy nam na wartościach w formacie int lub float) oraz modelu interfejsu użytkownika (gdzie naprawdę chcemy umożliwić użytkownikowi włożyć wszystko, co chcą).

Aby dane mogły migrować z modelu interfejsu użytkownika do modelu biznesowego, musi przejść przez etap sprawdzania poprawności (może się to zdarzyć w zależności od pola, ale większość scenariuszy wymaga sprawdzenia poprawności na całym obiekcie, jest konfigurowany).

Jeśli sprawdzanie poprawności nie powiedzie się, użytkownik otrzyma informację zwrotną informującą o tym, co zrobił źle i ma szansę go naprawić.

Biblioteki wiążące, takie jak JGoodies Binding i JSR 295, sprawiają, że tego typu rzeczy są łatwiejsze do wdrożenia, niż mogłoby się wydawać - a wiele frameworków internetowych udostępnia konstrukcje, które oddzielają dane użytkownika od rzeczywistego modelu biznesowego, a jedynie wypełnianie obiektów biznesowych po sprawdzeniu poprawności kompletny.

Jeśli chodzi o sprawdzanie poprawności plików konfiguracyjnych (drugi przypadek użycia przedstawiony w niektórych komentarzach), to jednoznaczne określenie wartości domyślnej, jeśli konkretna wartość nie jest określona w ogóle - ale jeśli dane są sformatowane źle (ktoś wpisuje "o" zamiast "zero" - lub skopiowano je z MS Worda, a wszystkie back-ticky mają funkową postać unicode), wtedy potrzebne są jakieś informacje zwrotne od systemu (nawet jeśli jest to po prostu nieudana aplikacja przez rzucanie wyjątek środowiska wykonawczego).

Answer 13

Integer.MIN_VALUE jako NumberFormatException to zły pomysł.

Możesz dodać propozycję projektu monety, aby dodać tę metodę Integer

@Nullable public static Integer parseInteger (src String) ... zwróci null dla złej wejścia

następnie umieścić link Twoja propozycja tutaj, a my wszyscy będziemy głosować na nią!

PS: Spójrz na to http://msdn.microsoft.com/en-us/library/bb397679.aspx ten sposób brzydki i wleczenia może być

Answer 14

Spróbuj org.apache.commons.lang.math.NumberUtils.createInteger(String s). To bardzo mi pomogło. Istnieją podobne metody dla podwójnych, długich itp.

Answer 15

Zapytałem if there were open source utility libraries that had methods to do this parsing for you, a odpowiedź brzmi: tak!

Od Apache Commons Lang można użyć NumberUtils.toInt:

// returns defaultValue if the string cannot be parsed. 
int i = org.apache.commons.lang.math.NumberUtils.toInt(s, defaultValue); 

Od Google Guava można użyć Ints.tryParse:

// returns null if the string cannot be parsed 
// Will throw a NullPointerException if the string is null 
Integer i = com.google.common.primitives.Ints.tryParse(s); 

Nie ma potrzeby, aby napisać własne metody do analizowania liczb bez rzucania wyjątków.

Answer 16

Cleaner semantyka (Java 8 OptionalInt)

Dla Java 8+, prawdopodobnie użyć wyrażenia regularnego do filtra wstępnego (w celu uniknięcia wyjątek jak zauważył), a następnie owinąć wynik w prymitywny opcjonalne (do czynienia z „domyślnego” problem):

public static OptionalInt toInt(final String input) { 
    return input.matches("[+-]?\\d+") 
      ? OptionalInt.of(Integer.parseInt(input)) 
      : OptionalInt.empty(); 
} 

Jeśli masz wiele wejść ciąg, można rozważyć zwrócenie IntStream zamiast OptionalInt dzięki czemu można flatMap().

Referencje

• RegEx podstawie parseInt documentation