BigDecimal compareTo and try catch block

[Jay Rex]

Please see the following code that compares bigDecimal objects:

import java.math.BigDecimal;
import java.math.RoundingMode;
import java.util.Scanner;

public class Test {
    public static void main(String[] args) {
 
        String input = "";
        int decimalPlaces = 2;
        BigDecimal result;
        BigDecimal upperLimit = new BigDecimal(99.99);
        BigDecimal lowerLimit = new BigDecimal(0.00);
        Scanner keyboardInput = new Scanner(System.in);
        
        System.out.print("Enter a value between 0 & 99.99: ");
        input = keyboardInput.next();
        try {
            result = new BigDecimal(input).setScale(decimalPlaces, RoundingMode.HALF_UP);
        }
        catch(Exception e) {
            System.out.println("Please enter a valid number.");
            System.exit(0);
        }
        result = new BigDecimal(input).setScale(decimalPlaces, RoundingMode.HALF_UP);
        if (result.compareTo(upperLimit) > 0 || result.compareTo(lowerLimit) < 0) {
            System.out.println("Please enter a valid number.");
            System.exit(0);
        } else {
            System.out.println("The number entered: " + result);
        }
    }
}

Please assist me with the following:

1. Why is it that if I enter 99.99, it enters the if loop and prints "Please enter a valid number". 99.99 is not greater than 99.99.
2. I am new to try catch blocks. I see that they have block scope. Lines 18 and 24 are duplicated, as it appears I have to check the code inside the try block and then duplicate the code outside the try catch block because that is what I want to do. Is this the correct way to do it?

Thank you.

[Paweł Baczyński]

Welcome to the Ranch!

Jay Rex wrote:1. Why is it that if I enter 99.99, it enters the if loop and prints "Please enter a valid number". 99.99 is not greater than 99.99.

Read carefully what condition you have in line 25. Write on pensil your calculation for input 99.99.

Jay Rex wrote:2. I am new to try catch blocks. I see that they have block scope. Lines 18 and 24 are duplicated, as it appears I have to check the code inside the try block and then duplicate the code outside the try catch block because that is what I want to do. Is this the correct way to do it?

It is not the correct way. If no exception is thrown then the value of result will aleady br set to desired value. No need to duplicate this. In this case the computation will be quick so no harm done, but if it were an expensive operation you might have a problem.

Also, I noticed that you use BigDecimal(double) constructor. Read the warning in corresponding javadoc so you are not surprised in the future.

[Campbell Ritchie]

Welcome to the Ranch

Don't use next() and try doing converting the result. Use next() when you want to get one token and use it as text. If you want a BigDecimal from a Scanner, that is what you should ask for: look here.

Don't use both > and <. Try != instead. [edit] That bit is there because I misread your original post. Sorry.

[Dave Tolls]

Paweł Baczyński wrote:
Read carefully what condition you have in line 25. Write on pensil your calculation for input 99.99.

That check is correct as far as I can see.

Paweł Baczyński wrote:
Also, I noticed that you use BigDecimal(double) constructor. Read the warning in corresponding javadoc so you are not surprised in the future.

This, though, is the cause of point (1).

[Knute Snortum]

If you're still stumped, try printing the values of upperLimit and lowerLimit.

[Jay Rex]

Paweł Baczyński wrote:Welcome to the Ranch!

Thank you for the welcome

Paweł Baczyński wrote:It is not the correct way. If no exception is thrown then the value of result will already be set to desired value. No need to duplicate this. In this case the computation will be quick so no harm done, but if it were an expensive operation you might have a problem.

The code has been corrected.

Campbell Ritchie wrote:Welcome to the Ranch

Thank you for the welcome

Campbell Ritchie wrote:Don't use next() and try doing converting the result. Use next() when you want to get one token and use it as text. If you want a BigDecimal from a Scanner, that is what you should ask for: look here.

I am trying to accept input from the user and if the input is not a valid number, it needs to throw an exception and exit. Is there a more efficient way to do that?

Dave Tolls wrote:This, though, is the cause of point (1).

Thank you.

Knute Snortum wrote:If you're still stumped, try printing the values of upperLimit and lowerLimit.

BigDecimal upperLimit = new BigDecimal(99.99); //99.9899999999999948840923025272786617279052734375
BigDecimal upperLimit = new BigDecimal("99.99"); //99.99

[Jay Rex]

Thank you for all the help. My code has reduced to the following:

import java.math.BigDecimal;
import java.math.RoundingMode;
import java.util.Scanner;

public class Test {
    public static void main(String[] args) {
 
        int decimalPlaces = 2;
        BigDecimal result = new BigDecimal("0");
        BigDecimal upperLimit = new BigDecimal("9999.99");
        BigDecimal lowerLimit = new BigDecimal("0");
        Scanner keyboardInput = new Scanner(System.in);
        
        System.out.print("Enter a value between 0 & 9999.99: ");
        try {
            result = keyboardInput.nextBigDecimal().setScale(decimalPlaces, RoundingMode.HALF_UP);
        }
        catch(Exception e) {
            System.out.println("Please enter a valid number.");
            System.exit(0);
        }
        if (result.compareTo(upperLimit) > 0 || result.compareTo(lowerLimit) < 0) {
            System.out.println("Please enter a valid number.");
            System.exit(0);
        } else {
            System.out.println("The number entered: " + result);
        }
    }
}

[Jay Rex]

My attempt at nextBigDecimal didn't work, so the following code works, but still uses next():

import java.math.BigDecimal;
import java.math.RoundingMode;
import java.util.Scanner;

public class Test {
    public static void main(String[] args) {
 
        int decimalPlaces = 2;
        BigDecimal input = new BigDecimal("0");
        BigDecimal upperLimit = new BigDecimal("9999.99");
        BigDecimal lowerLimit = new BigDecimal("0");
        Scanner keyboardInput = new Scanner(System.in);
        
        System.out.print("Enter a value between 0 & 9999.99: ");
        try {
            input = new BigDecimal(keyboardInput.next())
                    .setScale(decimalPlaces, RoundingMode.HALF_UP);
        }
        catch(Exception e) {
            System.out.println("Please enter a valid number.");
            System.exit(0);
        }
        if (input.compareTo(upperLimit) > 0 || input.compareTo(lowerLimit) < 0) {
            System.out.println("Please enter a valid number.");
            System.exit(0);
        } else {
            System.out.println("The number entered: " + input);
        }
    }
}

[Paweł Baczyński]

Dave Tolls wrote:That check is correct as far as I can see.

It looks like it is. My bad.

[Campbell Ritchie]

Who needs an exception? The three exceptions you are likely to see are NoSuchElementException (NSEE) IllegalStateException (ISE) and InputMismatchException (IME). You can avoid NSEE and ISE by not closing the Scanner, nor closing System.in with ctrl‑D or ctrl‑Z. But you already know not to close such objects. A long time ago, Rob Spoor taught me that you can avoid an IME with a simple loop:-

// ...
while (!myScanner.hasNextBigDecimal())
{
   System.out.print("Incorrect format: please try again: ");
   myScanner.next();
}
BigDecimal number = myScanner.nextBigDecimal();
// ...

Ideally, that loop belongs in a method in a utility class, but you probably haven't got enough time to write a utility class now. The loop makes sure anything not matching the required pattern will simply be rejected, so no risk of an IME.Goodbye, try and goodbye, catch. Also goodbye, rounding; you don't need to round anything. It will cope with input like 123456789.012345678901234567890123456789 quite happily.
Avoid System.exit. It won't do any harm in a simple app like this, but it can do serious damage in multi‑threaded programs.

[Knute Snortum]

BigDecimal upperLimit = new BigDecimal("9999.99"); It looks like you still have the problem of rounding your input but not your upper and lower limits.

[Campbell Ritchie]

Do you need new BigDecimal("0") when you can use this?

[Jay Rex]

Campbell Ritchie wrote:Who needs an exception?

Superb answer, thank you. I've implemented that code.

Campbell Ritchie wrote:Avoid System.exit

Noted, thank you.

Knute Snortum wrote:It looks like you still have the problem of rounding your input but not your upper and lower limits.

For this small program, rounding the input is appropriate.

Campbell Ritchie wrote:Do you need new BigDecimal("0") when you can use this?

Thank you again Implemented.

The following code doesn't work, but I want to try and condense the logic further by doing the following:

while (!keyboardInput.hasNextBigDecimal() 
		&& (keyboardInput.hasNextBigDecimal().compareTo(upperLimit) > 0
		|| keyboardInput.hasNextBigDecimal().compareTo(lowerLimit) < 0)) {

How do I correct this:

keyboardInput.hasNextBigDecimal().compareTo(upperLimit) > 0

so that it returns a boolean?

[Campbell Ritchie]

Jay Rex wrote:. . . The following code doesn't work, but I want to try and condense the logic further by doing the following:

while (!keyboardInput.hasNextBigDecimal() 
		&& (keyboardInput.hasNextBigDecimal().compareTo(upperLimit) > 0
		|| keyboardInput.hasNextBigDecimal().compareTo(lowerLimit) < 0)) {

. . .

You are comparing a boolean from a hasNextXXX() method to a BigDecimal from the nextXXX() method; that won't compile.You need to compare nextBigDecimal() against the limits. So you change it to this:-

while (!keyboardInput.hasNextBigDecimal() 
		&& (keyboardInput.nextBigDecimal().compareTo(upperLimit) > 0
		|| keyboardInput.nextBigDecimal().compareTo(lowerLimit) < 0)) {

. . . and it will compile. I am keeping quiet about the serious error hidden in that code, however.

You do need a utility class after all.

package resources;

import java util.Scanner;

public cllass KeyboardInputs
{
   private static final Scanner scanner = new Scanner(System.in);

   private KeyboardInputs()
   {
      // empty   I'll leave you to find out why
   }

   public static boolean hasNextBigDecimal()
   {
      return scanner.hasNextBigDecimal();
   }

   public static BigDecimal nextBigDecimal()
   {
      while (!scanner.hasNextBigDecimal())
      {
         System.out.print("Incorrect format: please try again: ");
         scanner.next();
      }
      return scanner.nextBigDecimal();
   }
}

You will need to add documentation comments, correct my spellling, and create methods for other values, e.g. nextInt(). Beware of nextLine() which needs some additional tweaking. Consider overloading methods to take customised error messages a parameters.

Now: overload those methods to return only values in a particular range. I think that will sort out your problem. Such ranges will be faster to achieve for primitives, e.g. ints, because you can simply use > and <.

[Knute Snortum]

Jay Rex wrote:Why is it that if I enter 99.99, it enters the if loop and prints "Please enter a valid number". 99.99 is not greater than 99.99.  

Knute Snortum wrote:If you're still stumped, try printing the values of upperLimit and lowerLimit.

Jay Rex wrote:

BigDecimal upperLimit = new BigDecimal(99.99); //99.9899999999999948840923025272786617279052734375
BigDecimal upperLimit = new BigDecimal("99.99"); //99.99

Knute Snortum wrote:It looks like you still have the problem of rounding your input but not your upper and lower limits.

Jay Rex wrote:For this small program, rounding the input is appropriate.  

I'm not sure what the length of you program has to do with it, but not rounding the upper and lower limit causes the problem you originally asked about.

[Campbell Ritchie]

I would prefer to use the BigDecimal(String) constructor or maybe BigDecimal#valueOf().

[Jay Rex]

Knute Snortum wrote:I'm not sure what the length of you program has to do with it, but not rounding the upper and lower limit causes the problem you originally asked about.

I used Campbell Ritchie's suggestion to use the String constructor instead, which has worked.

Campbell Ritchie wrote:Rob Spoor taught me that you can avoid an IME with a simple loop:-

Unfortunately, the loop doesn't work. It only works for int input, not for floating point input.

while (!keyboardInput.hasNextBigDecimal()) {
    System.out.print("Enter a value between 0 & 9999.99: ");
    keyboardInput.next();
}

Example: 1 passes the while loop, but 1.1 does not pass. If I type hello or 1.1, it has the same result, which is to ask for input again.

[Knute Snortum]

Hmm.. it works for me.  Are you using it like this?

import java.io.IOException;
import java.math.BigDecimal;
import java.util.Scanner;

public class FileReaderPlay {
	private Scanner keyboardInput = new Scanner(System.in);

	public static void main(String args[]) throws IOException {
		new FileReaderPlay().run();
	}

	private void run() {
		System.out.print("Enter a decimal: ");
		BigDecimal decimal = nextBigDecimal();
		System.out.println(decimal);
	}

	public BigDecimal nextBigDecimal() {
		while (!keyboardInput.hasNextBigDecimal()) {
			System.out.print("Incorrect format: please try again: ");
			keyboardInput.next();
		}
		return keyboardInput.nextBigDecimal();
	}
}

[Campbell Ritchie]

Jay Rex wrote:. . . Unfortunately, the loop doesn't work. It only works for int input, not for floating point input.  . . .

I can see nothing wrong with your loop. Unless you live somewhere not using a full stop as the decimal point. Please give us the full details of what goes wrong.

[Jay Rex]

Knute Snortum wrote:Hmm.. it works for me.  Are you using it like this?

Thank you for your code example. I coped your code verbatim. It compiles but has the same problem that I'm currently experiencing. Please see below.

Campbell Ritchie wrote:I can see nothing wrong with your loop. Unless you live somewhere not using a full stop as the decimal point. Please give us the full details of what goes wrong.

I live in a place where the full stop is the decimal point.

Here is the command line printout:
λ javac FileReaderPlay.java λ java FileReaderPlay Enter a decimal: 1 1                 λ java FileReaderPlay                       Enter a decimal: hello                     Incorrect format: please try again: this   Incorrect format: please try again: is     Incorrect format: please try again: a       Incorrect format: please try again: decimal Incorrect format: please try again: 1.1     Incorrect format: please try again: 10.0   Incorrect format: please try again: 0.00   Incorrect format: please try again: 99.99   Incorrect format: please try again: ?       Incorrect format: please try again: 1       1                                          

[Jay Rex]

This seems to be a locale issue, as the decimal works if I enter a comma, which is not correct for where I live, nor is it correct in terms of the code I submitted at the beginning of this thread which didn't include hasNextBigDecimal().


λ java FileReaderPlay Enter a decimal: 1.1 Incorrect format: please try again: 1,1 1.1

[Campbell Ritchie]

It does sound like a locale issue, which is why the full stop didn't help. Try System.out.println(Locale.getDefault());

[Jay Rex]

Campbell Ritchie wrote:It does sound like a locale issue, which is why the full stop didn't help.

The problem is not with System.out.println(). That prints the correct value with a full stop. The problem is that when I introduced !keyboardInput.hasNextBigDecimal(), it no longer recognised the full stop as a decimal place.

The output is correct, but only if I use a comma. It is as if hasNextBigDecimal() ignores my locale, but then System.out.println() gets it right again.

[Campbell Ritchie]

but what did you get when you printed your Locale?

[Jay Rex]

It prints the correct locale for my country.

[Campbell Ritchie]

Where's that? Is it somewhere where people speak several languages?

[Jay Rex]

The Locale is en_ZA.

The locale uses the period as the decimal point.

[Campbell Ritchie]

Yes, I think en_ZA should use full stop. Maybe it would use comma if you went into Afrikaans or Xhosa or similar.
Don't declare IOException; that code doesn't throw such an Exception.
I tried your code unchanged, but without the IOException, ad got this:-java FileReaderPlay Enter a decimal: kbbkd Incorrect format: please try again: Campbell Incorrect format: please try again: 1,2 Incorrect format: please try again: ? Incorrect format: please try again: 1.234 1.234I am using en_GB (or maybe en_UK) as my locale. Try changing the Locale on your system. I tried using System.getProperties orsimilar to print oiut informaton about my installation and got the following:

java PropertiesList
The property awt.toolkit   . . .
The property user.country                   is GB
. . .
The property user.language                  is en
. . .

So you can work out the locale from that. Try moving your Locale: System.setProperty("user.country", "GB"); System.setProperty("user.language", "en");
See whether that makes any difference.

[Jay Rex]

Doesn't this constitute a bug in the JVM, if the locale is not adhered to?

According to the locale on my system, it is en_ZA.

It shouldn't matter what language I use, as the locale is defined for the country, not the language.

Changing the locale fixes the problem, but I don't live in the states, or anywhere else. It needs to honour my existing locale.

Should I submit this as a bug?

[Stephan van Hulst]

It's probably not.

Please assign Locale.getDefault(Locale.Category.FORMAT) to a variable locale and print it, as well as DecimalFormatSymbols.getInstance(locale).getDecimalSeparator().

[Jay Rex]

Stephan van Hulst wrote:It's probably not.

The code:

import java.util.Locale;
import java.text.DecimalFormatSymbols;

public class GetLocaleInformation {
    public static void main (String[] args) {
        
        System.out.println(Locale.getDefault());
        
        Locale locale = Locale.getDefault(Locale.Category.FORMAT);
        System.out.println(locale);
        System.out.println(DecimalFormatSymbols.getInstance(locale).getDecimalSeparator());
    }
}

The output:
λ java GetLocaleInformation en_ZA en_ZA ,

Further investigation:

https://www.sadev.co.za/content/how-correctly-format-currency-south-africa

I have never seen this in practice, anywhere, ever.

So, learning Java has taught me something I never knew about my own country.

Is the best way forward, for me to add the following to my code?

Locale.setDefault(new Locale("en","US"));

[Stephan van Hulst]

It depends. If you want to use the user's native formatting, then no, just use the default.

If you want to use the same format regardless of the user's locale, use the root locale, which is not specific to any culture (although most of its settings are the same as the English locale). Even so, don't override the default locale. Just configure your scanner properly:

scanner.useLocale(Locale.ROOT);

[Campbell Ritchie]

I had quite forgotten that you can set a Locale for a Scanner; it is worth getting the Locale and viewing it with myScanner.locale(). Note that Scanner has different names for its getXXX and setXXX methods from everybody else.

[Campbell Ritchie]

I enhanced your code to change Locale:-

import java.math.BigDecimal;
import java.util.Locale;
import java.util.Scanner;
 
public class FileReaderPlay {
    private Scanner keyboardInput = new Scanner(System.in);
    private Locale locale = new Locale("en", "GB");
 
    private FileReaderPlay(String[] args)
    {
        if (args.length > 1)
        {
            locale = new Locale(args[0], args[1]);
        }
        keyboardInput = new Scanner(System.in);
        keyboardInput.useLocale(locale);
    }
 
    public static void main(String args[]) {
        new FileReaderPlay(args).run();
    }
 
    private void run() {
        System.out.print("Enter a decimal: ");
        BigDecimal decimal = nextBigDecimal();
        System.out.printf("%f Locale = %s%n",
                decimal.add(BigDecimal.ONE), locale);
    }
 
    public BigDecimal nextBigDecimal() {
        while (!keyboardInput.hasNextBigDecimal()) {
            System.out.print("Incorrect format: please try again: ");
            keyboardInput.next();
        }
        return keyboardInput.nextBigDecimal();
    }
}

java FileReaderPlay Enter a decimal: djfgkdf Incorrect format: please try again: 1,2 Incorrect format: please try again: 1,234,566.89 1234567.890000 Locale = en_GB [critchie@xxxx java]$ java FileReaderPlay en ZA Enter a decimal: jdsfgkdf Incorrect format: please try again: 1.2 Incorrect format: please try again: 1.234.566,89 Incorrect format: please try again: 1234566.89 Incorrect format: please try again: 1234566.89 Incorrect format: please try again: 1234566,89 1234567.890000 Locale = en_ZANote that plain simple %f defaults to six places after the decimal point.

[Jay Rex]

Thank you for all the help. This has been most enlightening.

[Campbell Ritchie]

That's a pleasure Interesting problem.

[Sthir Vidyut]

For Query 1: The problem is that the number 99.99 can't be represented exactly as a double, so it is represented by closet double value. Unfortunately, which is not much closer to 99.99. e.g The same problem you would found when you to see the output of the  statement

System.out.println(2.00-1.10);

. The best solution you already got in above discussion that always use the BigDecimal(String) constructor instead of BigDecimal(Double).

For Query 2: You can simplify the code as like below in the try catch block:

try {
           result = new BigDecimal(input).setScale(decimalPlaces, RoundingMode.HALF_UP);
           if (result.compareTo(upperLimit) > 0 || result.compareTo(lowerLimit) < 0) {
               System.out.println("Please enter a valid number.");
               System.exit(0);
           }
           else {
               System.out.println("The number entered: " + result);
           }
       }
       catch(Exception e) {
           System.out.println("Please enter a valid number.");
           System.exit(0);
       }

[Knute Snortum]

Welcome to the Ranch, Sthir Vidyut!

Thank you for attempting to UseCodeTags (that's a link).  However, you need to insert your code in between tags or it doesn't work.  To make sure you've got it right, use the Preview button, right next to the Submit button.