2014-02-12 2 views
0

Я знаю, что java замыкает свои булевы оценки. Итак, если (false & & true) не достигнет истинного условия, так как java уже знает, что первое является ложным.Java regex соответствует целому числу

У меня проблема. Я должен проверить, является ли вход положительным целым числом и меньше другого целого.

условие выглядит следующим образом:

if (inputIsPositiveInteger(input) && inputIsLessThanSomeNumber(input,someNumber)) { 
     doSomething(); 
    } 

    boolean inputIsPositiveInteger(String input) { 
     String regex = "[0-9]*"; 
     return input.matches(regex); 
    } 

    boolean inputIsLessThanSomeNumber(String input, String someNumber) { 
     return (Integer.parseInt(input) < Integer.parseInt(someNumber)); 
    } 

Это проливает NumberFormatException, если мой вклад не является целым числом, так как я разборе вход на Integer во втором состоянии. Я думал, что если первое условие было ложным, оно просто выйдет из оператора if.

Может ли кто-нибудь пролить свет на это?

java.lang.NumberFormatException: For input string: "a" 
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
    at java.lang.Integer.parseInt(Integer.java:492) 
    at java.lang.Integer.parseInt(Integer.java:527) 
    at com.akolopez.servlets.ProductServlet.inputIsLessThanStock(ProductServlet.java:94) 
    at com.akolopez.servlets.ProductServlet.validateInput(ProductServlet.java:78) 
    at com.akolopez.servlets.ProductServlet.doPost(ProductServlet.java:70) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) 
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) 
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) 
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) 
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) 
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) 
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) 
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929) 
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) 
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) 
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002) 
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) 
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
    at java.lang.Thread.run(Thread.java:744) 

Редактировать: обновил мое сообщение другими методами. Edit2: Я добавил трассировку стека, если это помогает.

+3

Можем ли мы увидеть оба метода тоже? И да, вы правы, 'if-statement' будет запускать' doSomething() ', если оба метода возвращают' true'. Это заставляет меня думать, что ошибка запускается при запуске одного из методов. – Tdorno

+0

Я отредактировал свое оригинальное сообщение двумя способами. – Akolopez

+3

Ваш 'inputIsPositiveInteger' также примет пустую строку' '' ', которая позже может вызывать' NumberFormatException'. Подумайте об использовании '+' вместо '*'. Также можете ли вы опубликовать более подробную информацию о заброшенном исключении? Трассировка стека была бы полезна. – Pshemo

ответ

0

Если вы не уверены, что ваш вход будет в правильном формате, вам нужно поймать это исключение. Например, вы можете сделать следующее:

try { 
    int x = Integer.parseInt(input); 
    int y = Integer.parseInt(someNumber); 
    if(x>0 && x<y) { 
     doSomething(); 
    } 
} catch(NumberFormatException e) { 
    // One of the inputs is not a number. 
} 

Это также, кажется, имеет смысл сделать так, потому что вы заботитесь о входах как целые, так преобразовать их в целые числа, а затем сделать ваши сравнения.

+1

Использование 'catch' как части логики - не лучший способ кодирования, и OP явно пытается избежать этого, проверяя его ввод, прежде чем использовать его в методе, который может вызвать исключение. – Pshemo

+0

Я не согласен. В случаях, когда вы не контролируете ситуацию (независимо от того, соответствует ли строка правильному формату), обработка исключений - отлично. На самом деле, сравните код выше, и кажется довольно очевидным, что использование обработки исключений не только короче, но и легче понять. – ferzle

+0

Код OPs может быть переписан многими способами, которые будут еще более читабельными, чем обработка исключений. Другой момент - это скорость. Повторное использование скомпилированных шаблонов регулярных выражений происходит быстрее, чем создание и обработка исключений. – Pshemo

2

Validate оба аргумента, input и someNumber:

void whatever(String input, String someNumber) { 
    if (inputIsLessThanSomeNumber(input, someNumber)) { 
     doSomething(); 
    } 
} 

boolean inputIsLessThanSomeNumber(String input, String someNumber) { 
    if (inputIsPositiveInteger(input) && inputIsPositiveInteger(someNumber)) 
    { 
     return (Integer.parseInt(input) < Integer.parseInt(someNumber)); 
    } 

    return false; 
} 

boolean inputIsPositiveInteger(String input) { 
    String regex = "[0-9]+"; 
    return input.matches(regex); 
} 
+0

Я согласен с этим. Кажется, что ОП не проверяет другой номер. Также '+' вместо '*' является хорошим предложением. '[0-9] *' соответствует пустой строке. – Radiodef

+0

I +1 это приятное улучшение, но OP утверждает, что реверсирование принятых символов регулярным выражением решает проблему, поэтому я боюсь, что это не все решение. – Pshemo

Смежные вопросы