为什么这个程序在jcreator上给出运行时错误而在netbeans上没有?

时间:2022-06-06 04:18:07

This is my solution for sphere's online judge palin problem. It runs fine on Netbeans, but the judge is rejecting my answer saying it gives a RuntimeError. I tried it on JCreator and it says:

这是我对球体在线判断问题的解决方案。它在Netbeans上运行良好,但法官拒绝我的回答说它给出了RuntimeError。我在JCreator上尝试过,它说:

Exception in thread "main" java.lang.NumberFormatException: For input string: ""
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
    at java.lang.Integer.parseInt(Integer.java:468)
    at java.lang.Integer.parseInt(Integer.java:497)
    at Main.main(Main.java:73)

I'm not passing an empty string for it to parse, why is this?

我没有传递一个空字符串来解析它,为什么会这样?

The code:

import java.io.*;
import java.util.*;



class Main {

    public static int firstPalinLargerThanNum(int num){

        int foundPalin =0;

        int evalThisNum = ++num;

        while (true){


        if (isPalin(evalThisNum))


            break;

        evalThisNum++;
        }

        foundPalin = evalThisNum;
        return foundPalin;

    }

    public static boolean isPalin(int evalThisNum){

           boolean isItPalin = false;

           int dig=0;
           int rev=0;


          int  n = evalThisNum;

          while (evalThisNum > 0)
          {

           dig = evalThisNum % 10;
           rev = rev * 10 + dig;
           evalThisNum = evalThisNum / 10;

          }

           if (n == rev) {

               isItPalin=true;
           }

           return isItPalin;

    }


    public static void main(String args[]) throws java.lang.Exception{

        BufferedReader r1 = new BufferedReader(new InputStreamReader(System.in));

        /*BufferedReader r1 = new BufferedReader (new FileReader(new File ("C:\\Documents and Settings\\Administrator\\My Documents\\NetBeansProjects\\Sphere\\src\\sphere\\sphere\\PALIN_INPUT.txt")));*/

        String read = r1.readLine();

        int numberOfTestCases = Integer.parseInt(read);

        for (int i=0; i<numberOfTestCases;i++){

        read = r1.readLine();

        if (read!=null){

        int num = Integer.parseInt(read);

        System.out.println(firstPalinLargerThanNum(num));

        }
        }
    }


}

Input:

2
808
2133

line 73 is: int num = Integer.parseInt(read);

第73行是:int num = Integer.parseInt(read);

4 个解决方案

#1


You will get that error if you hit <Enter> when the program is expecting a number.

如果在程序期望数字时按 键,则会出现该错误。

Suppose your input is

假设您的输入是

2
3 
<Enter>

You will receive the error you have indicated after processing the number 3, as you have told your routine to iterate twice.

您将在处理完第3号后收到错误,因为您告诉您的例行程序要重复两次。

As an aside, on top of error handling around the number parsing, you might also want to introduce a trim() to the readLine() method calls:

顺便说一下,除了数字解析的错误处理之外,您可能还想在readLine()方法调用中引入trim():

String read = r1.readLine().trim();

This will allow you to handle gracefully the input in the event that the user to put in whitespace around the numbers.

这将允许您在用户放入数字周围的空格的情况下优雅地处理输入。

#2


Just a wild guess: Could there be a problem with different end-of-line separators. E.g. your program actually gets 2<CR><LF>808<CR><LF>2133<CR><LF>, thinks that the line ends at the <CR> and processes the line.

只是一个疯狂的猜测:不同的行尾分隔符可能存在问题。例如。你的程序实际得到2 808 2133 ,认为该行在 处结束并处理该行。

Now when it tries to process the next line it finds <LF> which makes it think it read an empty String.

现在,当它试图处理下一行时,它找到 ,这使它认为它读取一个空字符串。

#3


You cannot assume that the user knows how to use your program and will give you correct input. The judge probably hit enter, without typing any number. How is he/she supposed to know the input that your program requires? A program should fail gracefully, not blow up in the user's face with cryptic errors.

您不能假设用户知道如何使用您的程序,并会给您正确的输入。法官可能在不输入任何号码的情况下击中了输入。他/她应该如何知道您的程序需要的输入?一个程序应该优雅地失败,而不是在用户的脸上因为神秘的错误而爆炸。

You should be doing something like the following, so that the user knows what to do:

您应该执行以下操作,以便用户知道该怎么做:

private static function readInt(BufferedReader reader) throws IOException
{
    boolean done = false;
    int result = -1;
    while ( ! done ){
       System.out.print("Please enter an integer: ");
       String str = reader.readLine();
       try{
          result = Integer.parseInt(str);
          done = true;
       }catch(NumberFormatException cantconvert){
          System.out.println("That isn't an integer. Try again.");
       }
    }
    return result;
}

Additionally, you shouldn't use an exception specifier with the main function (that is, don't use "throws" in the signature of "main"). You should handle those IOExceptions and print a pretty and intelligible message to the user, even if there is nothing you can do about the exception to fix it or make it go away.

此外,您不应该使用带有main函数的异常说明符(即,不要在“main”的签名中使用“throws”)。您应该处理这些IOExceptions并向用户打印一个漂亮且可理解的消息,即使您无法对异常进行修复或使其消失。

#4


I just ran your example code under Eclipse 3.4 without error. I was only able to induce a similar error when I did not provide the specified number of test cases, i.e.:

我只是在Eclipse 3.4下运行您的示例代码而没有错误。当我没有提供指定数量的测试用例时,我只能引起类似的错误,即:

6
56
87
[Enter]

So I am inclined to agree with akf that there must be an extra Enter happening somewhere, because this error will only be generated when there are insufficient lines of input.

所以我倾向于同意akf某些地方必须有一个额外的Enter事件,因为只有在没有足够的输入行时才会产生这个错误。

#1


You will get that error if you hit <Enter> when the program is expecting a number.

如果在程序期望数字时按 键,则会出现该错误。

Suppose your input is

假设您的输入是

2
3 
<Enter>

You will receive the error you have indicated after processing the number 3, as you have told your routine to iterate twice.

您将在处理完第3号后收到错误,因为您告诉您的例行程序要重复两次。

As an aside, on top of error handling around the number parsing, you might also want to introduce a trim() to the readLine() method calls:

顺便说一下,除了数字解析的错误处理之外,您可能还想在readLine()方法调用中引入trim():

String read = r1.readLine().trim();

This will allow you to handle gracefully the input in the event that the user to put in whitespace around the numbers.

这将允许您在用户放入数字周围的空格的情况下优雅地处理输入。

#2


Just a wild guess: Could there be a problem with different end-of-line separators. E.g. your program actually gets 2<CR><LF>808<CR><LF>2133<CR><LF>, thinks that the line ends at the <CR> and processes the line.

只是一个疯狂的猜测:不同的行尾分隔符可能存在问题。例如。你的程序实际得到2 808 2133 ,认为该行在 处结束并处理该行。

Now when it tries to process the next line it finds <LF> which makes it think it read an empty String.

现在,当它试图处理下一行时,它找到 ,这使它认为它读取一个空字符串。

#3


You cannot assume that the user knows how to use your program and will give you correct input. The judge probably hit enter, without typing any number. How is he/she supposed to know the input that your program requires? A program should fail gracefully, not blow up in the user's face with cryptic errors.

您不能假设用户知道如何使用您的程序,并会给您正确的输入。法官可能在不输入任何号码的情况下击中了输入。他/她应该如何知道您的程序需要的输入?一个程序应该优雅地失败,而不是在用户的脸上因为神秘的错误而爆炸。

You should be doing something like the following, so that the user knows what to do:

您应该执行以下操作,以便用户知道该怎么做:

private static function readInt(BufferedReader reader) throws IOException
{
    boolean done = false;
    int result = -1;
    while ( ! done ){
       System.out.print("Please enter an integer: ");
       String str = reader.readLine();
       try{
          result = Integer.parseInt(str);
          done = true;
       }catch(NumberFormatException cantconvert){
          System.out.println("That isn't an integer. Try again.");
       }
    }
    return result;
}

Additionally, you shouldn't use an exception specifier with the main function (that is, don't use "throws" in the signature of "main"). You should handle those IOExceptions and print a pretty and intelligible message to the user, even if there is nothing you can do about the exception to fix it or make it go away.

此外,您不应该使用带有main函数的异常说明符(即,不要在“main”的签名中使用“throws”)。您应该处理这些IOExceptions并向用户打印一个漂亮且可理解的消息,即使您无法对异常进行修复或使其消失。

#4


I just ran your example code under Eclipse 3.4 without error. I was only able to induce a similar error when I did not provide the specified number of test cases, i.e.:

我只是在Eclipse 3.4下运行您的示例代码而没有错误。当我没有提供指定数量的测试用例时,我只能引起类似的错误,即:

6
56
87
[Enter]

So I am inclined to agree with akf that there must be an extra Enter happening somewhere, because this error will only be generated when there are insufficient lines of input.

所以我倾向于同意akf某些地方必须有一个额外的Enter事件,因为只有在没有足够的输入行时才会产生这个错误。