Why conditions 2 and 3 are not met?

Question about the task

Under discussion

2 condition: The program should display 5 numbers, each on a new line. 3 condition: The output must contain the same numbers that were entered (order is not important).

package com.codegym.task.task06.task0622; import java.io.BufferedReader; import java.io.InputStreamReader; import java.util.ArrayList; import java.util.Comparator; import java.util.List; /* Ascending numbers */ public class Solution { private static int count = 0; public static void main(String[] args) throws Exception { //reading List<Integer> il = readInts(5); //sorting il.sort(Comparator.comparingInt(Integer::intValue)); //displaying il.forEach(System.out :: println); } public static List<Integer> readInts(int count) { List<Integer> intList = new ArrayList<>(count); try(BufferedReader reader = new BufferedReader(new InputStreamReader(System.in))) { while (Solution.count < count) { intList.add(Solution.count, Integer.parseInt(reader.readLine())); Solution.count++; } } catch (Exception ex) { ex.printStackTrace(); } return intList; } }

Comments (9)

Popular
New
Old

You must be signed in to leave a comment

crispr_cast9

Level 9 , Saint Petersburg, Russian Federation

27 December 2021, 09:14

Спасибо. Тоже думал про printStackTrace. Нужно будет почитать про валидатор.

Gellert Varga

Level 23 , Szekesfehervar, Hungary

26 December 2021, 20:23

1) it's nice to use the try-catch structure, but printing the StackTrace is not what this task asks you to do. Strive to print strictly only what the task asks you to print, otherwise you may quickly get a failure from the validator. 2) (and this point will probably be the more important factor) Strive to never use a static variable unless absolutely necessary, or unless the task asks you to. Using static variables will tend to cause the code to fail the validator. The use of static variables is also not too compatible with the OOP approach. (Of course, sometimes it is necessary.) In this case, you can easily replace it with a local variable in the readInts() method.

Gellert Varga

Level 23 , Szekesfehervar, Hungary

26 December 2021, 20:28

P.S: Unfortunately, you should not always take seriously which requirement is marked as not fulfilled. Sometimes the problem is quite different from what the validator flags.

Lisa

Level 41

27 December 2021, 13:34

I'm with you here, the biggest problem is the use of a static variable. Even if CG would not mind statics here, its usage will lead to problems. Imagine the validation process is creating several Solution objects and running different tests on them. The first test run seem to be OK. But in the second, Solution.count is 5 whilst there is a new, empty list. Addressing the 6th element in an empty ArrayList will lead to an exception and the validation process won't see the expected result, the five numbers are missing, requirements 2 and 3 not met. As a side note, it is superfluous to pass a Comparator to the sort method as the default sort order already is ascending. Instead you just could write:

il.stream()
        .sorted()
        .forEach(System.out::println);

Oh, and if really outputting the stack trace is a problem you either could a) omit using try catch and throw up the exception the stack trace or b) keep the try-catch block and instead of outputting the stack trace you rethrow a RuntimeException Just keep in mind that neither rethrowing a RuntimeException nor printing the stack trace is proper exception handling.

Gellert Varga

Level 23 , Szekesfehervar, Hungary

27 December 2021, 20:04

What is considered proper handling of an Exception?

Lisa

Level 41

28 December 2021, 08:59

Depends on the exception, where it occurs, the code... In a perfect world you'd set back the program into a state where it can continue running without a problem. But it has not to be where the exception occurs (if you do not know at that time what to do). But that is not always that easy and there are sometimes a lot of exceptions you need to handle. I doubt you're willing to write code for each to take care of all possibilities. In real life it is probably more logging, closing resources and saving state (and then closing the program). For the CodeGym programs I think it's best to rethrow a runtime exception. That does not output text whilst the runtime of your program (like you do with printStackTrace) but delegates the same output to the JVM. Means you transform a checked exception into an unchecked one (that you do not need to handle anymore).

try {
    throw new IOException("An exception, oh on!");
} catch (IOException ioe) {
    throw new RuntimeException(ioe);
}

Gellert Varga

Level 23 , Szekesfehervar, Hungary

28 December 2021, 21:32

Sorry, I'm a difficult case...;) I guess I didn't understand something very well about throwing a RuntimeException. I tried the little program below, and my expectation was that it would throw any Exception message only after printing the result. Instead, the program stopped and only the nested Exception message was displayed. Only by using printStackTrace I could get prg to run in normal mode until the end, print the result, and only then print an Exception message.

public static void main(String args[])  {
   int x=10;
   int y=0;
   int z=0;

   try {
     z = x/y;
   }
   catch (Exception exc) {
       throw new RuntimeException(exc);
     //  exc.printStackTrace();
   }

   System.out.println("Result of divide: " + z);
 }

After all what is the sense/profit of throwing a new RuntimeException?

Lisa

Level 41

29 December 2021, 08:09

This is exactly the expected behaviour... it takes the Throwable (the original exception), passes it to the RuntimeExceptions constructor and that way ends the program. You get shown what caused the problem (the original exception but you can pass the constructor an additional string with your own remarks). Whats the benefit? That the program ends and does not continue to run in a probably unknown state. As said, this is an alternative to just print the stack trace. Both are no exception handling. Printing the stack trace continues the program but you don't know in what state. If you have a gui program you most probably won't even see the output on the console and at a certain point your prog will start to act weird. It even may corrupt later added/ edited data. Or you just continue working with wrong data. So ending the program may be the better of those two possibilities if you omit error handling. At least you know right away that a problem occurred. Better of course would be if you try to recover from the problem, set state back to a working state and continue, save, log, whatever (but that's never asked here on this site nor are the programs complex enough to justify the effort). Another point is that converting exceptions to runtime exceptions works well on CG 🥳 In the end you decide which way you go.

Gellert Varga

Level 23 , Szekesfehervar, Hungary

29 December 2021, 20:26

OK, thanks for the explanations!