NumberFormatException error (parseInt)
Asked Answered
R

2

5

Hopefully a very simple query, but it's left me scratching my head.

I have a string, which is just a single integer, and I'm trying to then get that integer out as an int. This on the face of it shouldn't be a problem.

// this is how I create the string (it's the playload from a UDP datagram packet, 
// thought I don't think the origins hugely important - it's juts a test run so the
// stringMessage is always 1 (created by a seperate client process)

  ...
  recvSoc.receive(pac);
  String stringMessage = new String(pac.getData());
  port = pac.getPort();
  System.out.println("RECEIVED: " + stringMessage + " on port:  " + port);
  processMessage(stringMessage);
  ...

// Then in processMessage

public void processMessage(String data) {
  int message;
  message = Integer.parseInt(data);
  ...

This always crashes with a NumberFormatException error. I cannot for the life of me figure out what's causing this, any ideas greatly appreciated. I haven't coded much in Java (recently) so might simply be forgetting something critical or what not.

Exception in thread "main" java.lang.NumberFormatException: For input string: "1"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:481)
at java.lang.Integer.parseInt(Integer.java:514)
at udp.UDPServer.processMessage(UDPServer.java:85)
at udp.UDPServer.run(UDPServer.java:52)
at udp.UDPServer.main(UDPServer.java:156)
Ridden answered 10/3, 2011 at 23:34 Comment(1)
print our your string character by character and see if anything is funny thereStroman
A
4

Note that DatagramPackate.getData() returns the whole buffer!

The data you received is only a part of it:

The data received or the data to be sent starts from the offset in the buffer, and runs for length long.

So to convert the data to a String you should use this constructor:

String message = new String(pac.getData(), pac.getOffset(), pac.getLength(), "UTF-8");

Note that I specify the UTF-8 encoding here, as not specifying an encoding would result in the platform default encoding to be used, which is generally not what you want.

Alexandra answered 11/3, 2011 at 7:52 Comment(1)
Perfect - I realized the 0s were messing it all up (I had assumed when the parseInt() method reached a 0 it would just stop, treating it like a /0) so got a workaround using a loop, but that's much nice - greatly appreciated!Ridden
G
5

If the string is really 1, the exception can't happen. So I would say the string is not actually 1.

do a data.toCharArray() and print each character's code (cast to int). It may turn out that there is a hidden character before the digit, for example. (edit: it appears iluxa mentioned this option in a comment while I was writing the answer)

Try data = data.trim() before passing it to parseInt(..)

Greenlaw answered 10/3, 2011 at 23:41 Comment(1)
So that's what I thought, but when I output that array all I get is an array containing a single element at zero which is 49 (1) and then the rest are empty (0). I can send different numbers instead of 1 and again, I get that number represented as you would expect as a series of ascii characters which map to the correct number, and then 0s. Is there some kind of null character in Java which maybe the getData method has forgotten?Ridden
A
4

Note that DatagramPackate.getData() returns the whole buffer!

The data you received is only a part of it:

The data received or the data to be sent starts from the offset in the buffer, and runs for length long.

So to convert the data to a String you should use this constructor:

String message = new String(pac.getData(), pac.getOffset(), pac.getLength(), "UTF-8");

Note that I specify the UTF-8 encoding here, as not specifying an encoding would result in the platform default encoding to be used, which is generally not what you want.

Alexandra answered 11/3, 2011 at 7:52 Comment(1)
Perfect - I realized the 0s were messing it all up (I had assumed when the parseInt() method reached a 0 it would just stop, treating it like a /0) so got a workaround using a loop, but that's much nice - greatly appreciated!Ridden

© 2022 - 2024 — McMap. All rights reserved.