Exception in thread "main"

[Epidilius]

Hi. The rest of my code works fine, but when I use a double my code crashes on line 32. I get a "Exception in thread 'main' java.lang.ArrayIndexOutOfBoundsException: 0
at Time.<init>(Time.java:32)
at Time.main(Time.java:55)" error.

My line 55 just calls up the Time constructor, so I doubt that it's the problem. I don't know why this keeps happening, and I can't fix it. Does anyone have any ideas?

[code]
Time ( double dec )
{
String s = Double.toString( dec );
String[] array = s.split(".");
int numWhole = Integer.parseInt(array[0]); <--- Line 32
int numDec = ((Integer.parseInt(array[1]))/10)*60;
System.out.println( numWhole + ":" + numDec + " Time double constructor" );
}
[\code]

[pbrockway2]

The array index in question is 0. So if it is out of bounds then array is an empty array (ie does not have an index 0).

You can check what is going on by printing the string s and/or the contents of the array.

Time ( double dec )
{
    String s = Double.toString( dec );
    [color=blue]System.out.println("In Time constructor: s is " + s);[/color]
    String[] array = s.split(".");
    int numWhole = Integer.parseInt(array[0]); <--- Line 32
    int numDec = ((Integer.parseInt(array[1]))/10)*60;
    System.out.println( numWhole + ":" + numDec + " Time double constructor" );
}

[Toll]

The problem is that s.split takes a regex as the argument, and "." is a regex wildcard for "any character". Since every part of s is "any character", it won't find anything to put into the array. As such, the array will be empty. Use s.split("\\.") instead.

[pbrockway2]

Agree... I didn't notice that!

I don't know about split("\\.") though. Double.toString() can return things without a dot in them and throwing an exception in this case would be a Good Thing. But it can also return things that will make the subsequent Integer.parseInt(array[1]) throw a NumberFormatException which is Less Good. Better in this case, I think, to avoid the quirkiness of toString() - and the dangers of regex - and fill the array by hand using the % operator. We start with a numerical quantity and we want to end up with an array of numerical quantities: why detour into dealing with Strings?

[Toll]

Actually, Double.toString(double) will always return a string with a dot in it.

class DoubleTest
{
  public static void main(String[] args)
  {
    double d=10;
    System.out.println(Double.toString(d));
  }
}

Output: 10.0

The problem with this, however, is: A string of 5.03 will throw a NumberFormatException: Integer.toInt(String s) isn't too happy about leading zeros. Could of course be dealt with in other ways. As for using %... That would return a double between 0 and 0.99999... which is hard to turn into an integer if you don't know how long it is. In that case, taking the String detour is an easier concept to grasp. However, if we decide that we want a maximum of a certain number of decimals taken into consideration, it becomes much easier, and it becomes far easier (and quicker by an order of fifty!) to use % and /.

[Junky]

Or if going down the String path do indexOf to get the location of the decimal point and then substring if it is greater than 0.

[Toll]

Hmm. I might have to retract the comment about Integer.toInt not being happy about leading zeros. I tried it again and it passed without a problem. Odd, because I got a NumberFormatException with such a string when I first tested. Must've been some trailing space or some such that I didn't see.

And yes, using indexOf is about three times faster than using split, so use that if possible.

[pbrockway2]

Actually, Double.toString(double) will always return a string with a dot in it.

I was thinking about "NaN" and "Infinity" which as I suggested may well deserve to throw an exception.

The NFEs will occur when toString() acts on an argument <10E-3 or >10E7.

I'm not completely sure what numDec is supposed to be. If formatting is important, then Strings would be good. But otherwise the OP now has three different approaches (split(), indexOf() and arithmetic operations) and should decide or try all three. And, maybe, let us know...