We use cookies to ensure you have the best browsing experience on our website. Please read our cookie policy for more information about how we use cookies.
Suggestion: Make the fourth testcase less strict. I had my catch outting... java.util.InputMismatchException: For input string: "2147483648"
When it expected... java.util.InputMismatchException
I simply made another catch for that specific exception and output "java.util.InputMismatchException" directy to work around it but I feel like that shouldn't be necessary. Unless simply printing out the Exception directly is the wrong way to go about it?
// These were my catchescatch(InputMismatchExceptione){System.out.println("java.util.InputMismatchException");}catch(Exceptione){System.out.println(e);}
If you use the Scanner class, you only need to catch the InputMismatchException and ArithmeticException to pass all the test cases. There is no need for a catch-all Exception.
Using a catch-all Exception clause is generally a bad idea when writing programs.
Fine, but what's the point of showing an exception message in a different way than the other? If you use that, it will give you an error when in the division by zero test case.
Why one exception should show the extra content and the other not? This is not even part of the exercise.
What they could do if they really want a nice representation of the exceptions, could be we print something like "This is an input mismatch exception" and "This is an arithmetic exception".
This would force people to know which exceptions could happen and don't use the generic Exception.
I did that, but then testcase 2 failed because it wanted "java.lang.ArithmeticException: / by zero" and you just get "java.lang.ArithmeticException" with this trick.
try{Scannersc=newScanner(System.in);intx=sc.nextInt();inty=sc.nextInt();if(y==0)thrownewArithmeticException("/ by zero");elseSystem.out.println(x/y);}catch(InputMismatchExceptione){System.out.println(e.getClass().getName());}catch(ArithmeticExceptione){System.out.println(e);}
public static void main(String[] args) {
/* Enter your code here. Read input from STDIN. Print output to STDOUT. Your class should be named Solution. */
Scanner sc = new Scanner(System.in);
try{
int x = sc.nextInt();
int y = sc.nextInt();
try{
int result = x/y;
System.out.println(result);
} catch(Exception e){
System.out.println("java.lang.ArithmeticException: / by zero");
}
} catch(Exception e){
System.out.println("java.util.InputMismatchException");
}
}
Here when you use e.getClass().getName(), .getClass() method will be returning the class of the exception and as we have used getName() method. we will get the name of the exception class.
so here :java.util.InputMismatchException: For input string: "2147483648"
class name is just "java.util.InputMismatchException"
If this was in school, I would have told the teacher to scew off. This is garabage. I could have had this challenge done in three lines of code. And having detailed exceptions for one thing and not another thing is a jerky thing to do. It goes against all coding conventions I was taught in school.
for other exceptions , we will have to first put specific catch block for that specific exceptions still if there is some possibility that other exception might get raised put a generic catch block for handeling all exceptions .
Java Exception Handling (Try-catch)
You are viewing a single comment's thread. Return to all comments →
Suggestion: Make the fourth testcase less strict. I had my catch outting...
java.util.InputMismatchException: For input string: "2147483648"When it expected...
java.util.InputMismatchExceptionI simply made another catch for that specific exception and output "java.util.InputMismatchException" directy to work around it but I feel like that shouldn't be necessary. Unless simply printing out the Exception directly is the wrong way to go about it?
Same here bro same here
If you use the
Scannerclass, you only need to catch theInputMismatchExceptionandArithmeticExceptionto pass all the test cases. There is no need for a catch-all Exception.Using a catch-all Exception clause is generally a bad idea when writing programs.
Instead of
we can use:
Fine, but what's the point of showing an exception message in a different way than the other? If you use that, it will give you an error when in the division by zero test case.
Why one exception should show the extra content and the other not? This is not even part of the exercise.
What they could do if they really want a nice representation of the exceptions, could be we print something like "This is an input mismatch exception" and "This is an arithmetic exception".
This would force people to know which exceptions could happen and don't use the generic Exception.
I did that, but then testcase 2 failed because it wanted "java.lang.ArithmeticException: / by zero" and you just get "java.lang.ArithmeticException" with this trick.
you can get "/ by zero" from ecxeption details message
`
can please explain this System.out.println(e.getClass().getName());
you prolly already understand this
Thank you ^_^
I look this it looks a lot cleaner then writing out the Arithmetic exception in the catch block. Thank you
This also works:
import java.io.; import java.util.; import java.text.; import java.math.; import java.util.regex.*;
public class Solution {
}
May be because you are using older version of java. In java 8 this code passes all the testcases successfully.
Hey can you tell me why the Test case 4th not showing:-
After using e.getClass().getName()
Here when you use e.getClass().getName(), .getClass() method will be returning the class of the exception and as we have used getName() method. we will get the name of the exception class.
so here :java.util.InputMismatchException: For input string: "2147483648"
class name is just "java.util.InputMismatchException"
What is the use of e.getClass().getName()
Yes, it's a poor problem.
I ended up doing...
as a way of stripping off the message.
rror: 'catch' without 'try' catch (InputMismatchException e){ ^
It was intentional.
I had assumed it was. It just seemed to me like an unnecessary hoop to have one jump through is all.
If this was in school, I would have told the teacher to scew off. This is garabage. I could have had this challenge done in three lines of code. And having detailed exceptions for one thing and not another thing is a jerky thing to do. It goes against all coding conventions I was taught in school.
And the purpose is?
thanx dude its work
wait you actually had to have try catches? I was just throwing exceptions around :P, no fun if you just print the stuff without crashing the program
Yes I have also done the same thing
Another way without any concern of the exception class:
can't it be possible that , we print the required output by using the object of exception we passed in the catch block .
Ex :
try {
}catch(InputMismatchException i) { System.out.println(i); }
above program print Exception with the causal , but the required output is without causal ?
By this u handled InputMismatchException......but what about other types of exception How u will handle them
for other exceptions , we will have to first put specific catch block for that specific exceptions still if there is some possibility that other exception might get raised put a generic catch block for handeling all exceptions .
Still not fixed :(
Here's my code. by using getClass().getName() you handle all exceptions that may occur.
Great approach, because while taking input only, exception will occur.